Skip to content

Google and Mountain View – the background to the dance

Most commentators on Hacker News had incomplete / wrong information.

Here is some basic background to help set the context.

  1. Google until recently basically ignored Mountain View south of 101. Until recently Google didn’t own anything south of 101.
  2. Google is not going anywhere. Mountain View is right next to Moffett Air field. This is where Larry and Sergey park their 767 ( http://techcrunch.com/2011/12/11/googles-3-top-executives-have-8-private-jets/ ) – Maybe Sunnyvale would be an alternative but I really doubt there are too many spots where L and S can be in walking distance of their 767. Furthermore Google is leasing a shit ass land from NASA to expand on.
  3. Its not just Google: Google, LinkedIn, Intuit, Symantec, all have HQs here. Microsoft/Nokia also have their research centers here.
  4. Google, et.al. subsides all services at their HQ as a result outside retail/restaurants have pretty much died north of 101. This results in local business owners/voters complaining to city council.
  5. Google woke up to the political problem when MV CC told Google that they were not going to be allowed build a connection bridge across Stevens Creek Trail for buses. ( a trail that MV residents worked 25 years to create )
  6. Google land purchases have resulted in increases in real-estate taxes, however Google generates NO sales tax revenue for the city. (same problem with the other companies)
  7. Land in North Bayshore has gotten so expensive that there is serious talk about putting a building on top of the VTA North County Maintenance Yard.
  8. Mountain View renters have seen Y/Y increases of about 20-25%. A 2 bedroom/2 bath apartment goes for $3300.
  9. The city planners have gotten so many building requests that the city has no staff to deal with the requests.
  10. The school districts have real problems keeping teachers – turnover for some schools runs 6-10%.
  11. Non-tech workers are being forced out – you know people like teachers, waiters, security guards. The MV Building inspectors have found entire families living in a single room ( http://mv-voice.com/news/2013/07/26/high-cost-housing-creates-desperate-living-conditions )
  12. The 3 new city council members are all pro-housing. The anti-housing candidates were rejected. Therefore comments along the lines of : stop whining and do something – well the new city council is doing something. Specifically, demanding that more housing gets built and less office space. We are trying to make room for the new people. In many cases these are our children.
  13. Google to its credit is starting to throw some money at Mountain View Capital Improvement Project list to help out.
  14. Google, Mountain View are working out a traffic management plan to reduce solo drivers – the whole of north bayshore is only accessible by 3 roads. Residents who live in north bayshore right now cannot get to/from their house between 8:30 and 10 and 4:30 and 6.
  15. Google is trying to be innovative and more inclusive with the city as a whole.

It would be excellent if more companies really improved the cities and communities they are in. Too often cities are place to mine for tax breaks and income.

There is more Google HW conversation at KQED.

Posted in political.

No comments

By pat – March 2, 2015

XML is not bad, just misused

There is the usual grumbling on Hacker News about XML

The problem isn’t with XML the problem is with the way it is used (or rather misused).

What are XMLs strengths:

  1. Valid files are definable. i.e. this element has a child elements or this element must contain only digits.
  2. Textual: errors are fixable with text editing tools.
  3. Textual: means compressible with gzip.
  4. all that “cruft”, “verboseness” makes XML files self-documenting. An XML element that looks like this:

    <FirstName>Pat</FirstName>

    is clearly containing a first name. A developer reading the XML can figure out the meaning of the data in order to extract the information.

    Binary formats are definitely NOT! self-documenting. Once the binary data layout description document is lost, the data is lost even if the file is still present. For binary formats, the “definition document” is often the code that created the file. Lose the program or the hardware that can run the program and the data is lost.

    JSON is NOT self-documenting either. Did XML need to be heavy with the open/close tag syntax – probably not but gzip exists for a reason.

  5. when a standards body needs to define industry-standard interchange formats: For example, filing information with the Security Exchange Commission.
  6. data persistence across years in a way that will survive the programs that created it. (SEC filings, Government filings, Drug testing data, etc.) Or even a standard way to describe the Bible.

Losing data for many applications is not that big a deal. Does it really matter if Google can’t read old search history logs from 5 years ago. Probably not. However, it does matter if the SEC can’t pull up security files from 5 years ago, because that filing might be relevant to a criminal probe of a bank (hah-hah).

Ask NASA how much they wish they could have recovered lost satellite data from the 1970s. Especially when trying to figure out the rate of climate change. Bitrot and technology obsolence is a problem that has been talked about for many years.

XML is really appropriate for the data persistent situation – where there is high value to the data being accessible years later.

XML is NOT a good choice for:

  1. API calls. No company should use XML-RPC. Tighter formats exists. XML is hard to parse on small devices. Just use HTTP semantics.
  2. Files whose loss is inconsequential.
  3. Data Serialization
  4. Transferring data between systems under the control of a single entity.
  5. Any situation that requires speedy parsing or generation of data.

There is a reason why XHTML didn’t last. XML and its constraints are not suitable for the transient world of web pages.

Like any other tool, XML’s purpose and limitations should be known and respected.

Don’t complain about XML being a poor solution for a problem it was not intended to solve.

Posted in rants, technical.

1 comment

By pat – December 6, 2014

California is awesome for business ( The myth of the importance of low taxes)

Really how important is business taxes? I talk about the myth of low tax utopia in this post.

The myth of the importance of low taxes

I decided to write this because of yet another debate on Hacker News about how California is somehow “losing” companies because of taxes:

You are thinking locally. Nobody cares where Tesla or Toyota build their cars. Having your business located “in the largest economy” isn’t a factor for a huge number of businesses.
Another way to put it is: You can build a massively successful business anywhere in the country. There is no particular magic in California in this regard. What is different here is that it cost more to simply exist in this state. And there’s far more to it than wages at play.

No one cares *where* their Tesla or Mazda is built. But they do care if it is built well.

Tesla does care if they can get qualified machinists to maintain the equipment that manufactures the Tesla. Sure Tesla can move to a random low tax location – and then spend years training the inexperienced low-quality workers available at the location.

It is possible, maybe. For low skill occupations, sure this is possible.

But the costs of running a business are much more than taxes and regulations:

  1. supply chain and logistics cost ( if suppliers are now further away there is now greater shipping and logistics management cost )
  2. infrastructure costs : does the selected location have an adequate power supply and transportation access
  3. Support services: everything from cleaners to the people who maintain the physical plant
  4. Access to airports so executives, customers, and suppliers can get to the plant
  5. relocation costs: moving existing infrastructure is not cheap.
  6. customer issues: if the company in question is in the middle of a supply chain: is the company now moving away from their primary customers facilities (which can make sales process more expensive and give less visibility to the customer needs)
  7. Will your key people agree to relocate?
  8. Is your key talent pool for new hires geographically fixed: There is a reason why Silicon Valley is successful place to be for software companies. There is a reason why New York/London is the place for finance. There is a reason why actors and actresses are in LA/New York/Bollywood : that is where the key talent is located.
  9. availability of labor: movies aren’t just about the actors and actresses. Film crews, set designers, lighting technicians, sound technicians, continuity experts, etc.: This is true for many, many industries. Detroit (area) is still the home of U.S. automakers for a reason.

So yes a business can make a decision based on taxes: Hollywood shoots movies in Vancouver, BC for a reason: but the main decisions and key talent are in LA and will always be in LA. Sure Mercedes-Benz could put a plant in Alabama and compel suppliers to move some facilities to be close to them. But could a MB supplier make the move on their own? No. That MB supplier can’t decide to move to North Dakota. Mercedes insists that part of the contractual agreement for their business is physical proximity.

When it comes to high value workers, California is the best:

  1. Non-compete agreements are unenforceable – I don’t have to worry that a job candidate will be blocked from joining my startup.
  2. Obamacare means that I can hire people from big companies without them having to worry about affordable healthcare.
  3. State government is pretty reasonable about things like Unemployment Insurance, etc. So I spend less time hassling with things.
  4. Lawyers and VCs have a reasonable attitude about certain things that make it easier to get shit done: less time dicking with screwy contracts: part of this is that California law makes some things illegal.
  5. educated population
  6. proximity to existing similar employers – new employees don’t have to relocate

Posted in marketing, political, rants.

No comments

By pat – October 23, 2014

Low business tax utopia myth

Really how important is business taxes?

Here is the TL;DR:

Businesses want the benefit of low taxes (lower immediate expenses) with the benefit of high taxes locations (government provide services that the business would otherwise have to pay).

But low tax utopia fails if no one pays high taxes needed to provide the services.

Basic business realities:

  1. Business depends on customers.
  2. Unemployment results in less customers
  3. Net costs must be lower than net revenue
  4. Customers must perceive a value to purchasing goods/service from the business at the price charged by the business
  5. It doesn’t matter how low cost the workers or the taxes are if there is no customers. A business without customers is out of business.
  6. If a business can get the benefit of a high-tax/high spending state without paying the taxes themselves, this is the best for that business.

Low tax utopia myth

That last point is critical. This is why companies try to get sweetheart tax deals to relocate to a state, city, or region. The business gets a lower tax rate than their competitors just down the street. The business gets the benefits of a quality infrastructure and a quality workforce at a discount.

Where the low tax utopia falls apart is when everyone gets their taxes lowered OR where the taxes are applied regressively so as to directly affect the ability of customers to buy goods.

An experiment has been conducted that proves this point. In 2012, California raised its taxes; Kansas slashed its income taxes and other taxes.

In 2014, California is paying down its debt and is able to fund services at a higher level, unemployment is falling. Obamacare has rolled out, health insurance premiums are dropping. California is planning for the future with a new water project, High Speed Rail, and education funding. California pays more in federal tax dollars than it receives. Governor Brown is cruising to an easy reelection, and as far as I can tell the Democrats are cruising on all statewide offices. I have not seen 1 TV ad nor received any mailer about any statewide office.

In 2014, Kansas’s state revenue is falling, schools are closing, economy is going down, unemployment is rising. Kansan debt is being downgraded by the rating agencies. Kansas is in survival mode. Gov. Sam Brownback is in serious trouble. Republicans are endorsing the Democratic challenger.

To summarize, in Kansas, low taxes resulted:

  1. in less employment
  2. lower services
  3. local businesses losing customers
  4. lower quality of life
  5. lower ability to invest in transportation infrastructure

This article from Forbes does a nice job of highlighting results of the Kansan experiment:

The tax cuts in Kansas have been breathtaking. In 2012, at Brownback’s urging, the legislature cut individual tax rates by 25 percent and repealed the tax on sole proprietorships and other “pass-through” businesses. It also increased the standard deduction (though it eliminated some individual credits as well).

In 2013, the legislature cut taxes again. It passed a measure to gradually lower rates even more over five years. By 2018, the top rate, which was 6.45 percent in 2012, will fall to 3.9 percent. It also partially restored some of the credits it eliminated in 2012. This time, it did raise some offsetting revenue for the first few years but far less than the statutory tax cuts. The Center on Budget & Policy Priorities wrote up a nice summary of all the tax changes.

So what happened after all those tax cuts? Revenues collapsed.

From June, 2013 to June, 2014, all Kansas tax revenue plunged by 11 percent. Individual income taxes fell from $2.9 billion to $2.2 billion and all income tax collections plummeted from $3.3 billion to $2.6 billion, a drop of more than 20 percent.

Besides, while Kansas individual income tax revenues bumped up a bit in 2013 over 2012 (as the fiscal cliff theory would suggest), the increase was only about $23 million. From 2013 to 2014, income tax revenue dropped by far more–by $713 million.

And that brings us to the bottom line. Since the first round of tax cuts, job growth in Kansas has lagged the U.S. economy. So have personal incomes. While more small businesses were formed, many of them were merely individuals taking advantage of the newly tax-free status of those firms by redefining themselves as businesses.

The business boom predicted by tax cut advocates has not happened, and it certainly has not come remotely close to offsetting the static revenue loss from the legislated tax cuts.

As Forbes says:

Kansas Governor Sam Brownback and his state legislature have embarked on a wonderful natural experiment. Once again we are testing the question: Can tax cuts pay for themselves? The answer– yet again– is a resounding no.

Posted in political.

1 comment

By pat – October 23, 2014

Yerka – a great innovation on making a bicycle unstealable!

What a great idea! For a thief to really profit from stealing this bike they have to do extra work. Plus they have to be willing to do this extra work while stealing the bike. They can’t just cut a chain and go.

The students built the first working prototype bike, code-named the Yerka Project. The bike’s down tube at the bottom of the frame splits apart and wraps around an object such as a post or tree, and the bike’s seat post is then slotted through both ends of the down tube to complete the lock. Once you’ve got everything in place, you simply take out the lock pin on the end of the down tube to seal the lock. The whole process takes less than 20 seconds, letting you be on your way in almost no time.

Clearly the any lock could be broken at some point but if the lock is in the seat post, it is very protected. If the Yerka bike makes the post not anchored to the frame portion then the post just spins if someone tries to break the lock with leverage.

Posted in great ideas, random silliness.

No comments

By pat – August 22, 2014

Do not let client code pick ids

I am having a discussion over on Meteor Hacks about how bad it is to let the client code pick ids.

The meteorhacks post shows how to make new items show up in a sample Meteor program before the server has completed its processing. The meteor folks call it latency compensation.

The problem is that latency compensation (in its current form) relies on the client code choosing the permanent id.

Template.addPost.events({
  "click button": function() {
    var title = $('#title').val();
    var content = $('#content').val();

    var post = {
      title: title,
      content: content,
      _id: Meteor.uuid()
    };

    Meteor.call('addPost', post, function(err) {
      if(err) {
        alert(err.reason);
      }
    });

    Router.go('/post/' + post._id);
  }
});

Key points for non-Meteor developers to be aware of:

  1. Meteor is a node.js framework. Server code is in javascript
  2. good Meteor code is written so as to be used both on the client and the server.
  3. Meteor has a ‘minimongodb’ that acts as a partial cache of the items in the server database.

Now if we rely on the client to select the database ids used by the server, there are a number of interesting attacks.

The original example was inserting new Posts. If we wanted to make a more exciting example, a permission table (i.e. Users or Roles could be the attack target).

Example #1: Insert race condition so the attacker can own the inserted post:

The attacker deliberately chooses an id known to exist. If the server code in question uses Posts.upsert() rather than Posts.insert() the attacker can modify an existing post and take control of the post.

Remember that in good Meteor code, the server and the client will share a lot of code, thus it is likely that an attacker could spot upsert() usages. But that isn’t really necessary.

The “counter” is “but, but the original insert will then fail”. However, lets use some real examples.

In the real world, the good client is trying to send the new post to the server over a flaky internet or to a busy server.

  1. The good client tries to send the new post but gets no response from the server.
  2. The good client tries again which succeeds on the server-side. However, the server response was lost.
  3. The good client tries a third time, the server reports the post exists.
  4. Finally, client then tells the server to please add that post to its ‘hot list of posts’ that is always displayed.

Flaky internet / busy servers are a fact of life.

Now make a slight alteration. On step #2 instead of the good client sending the second attempt it is really the attacker.

  1. The good client tries to send the new post but gets no response from the server.
  2. The good client tries againThe attacker sends a post insert which succeeds on the server-side.
  3. The good client tries a second time, the server reports the (attacker’s) post exists.
  4. Finally, client then tells the server to please add the attacker’s post to its ‘hot list of posts’ that is always displayed.

But how could the attacker know the the id that the client used? ( see below for that answer)

Example #2: (modifying an existing record).

However, if instead of Posts.insert() the post creation code is using upsert then the malicious client can happily modify whatever it wants into the database. Because the post upsert code is shared between client and server. The malicious hacker can just scan the code looking for places where upsert is used.

“But, but why would anyone use upsert on Posts creation?” Why was upsert created? Because it is useful for cases where the developer does not want to do a query + insert combination. Client id generation + upsert() = attacker fun.

This can be most fun in situations where an attacker can grant some privileges to the victim. So the victim’s call look successful, but the attacker can still control the database Post entry.

Example #3: ( Flooding the Db – and why the attacker does not need to know the actual id generated)

This is a brute force attack – but lets say that there was a weakness in the way the client chose the id. A predictable pattern. Remember uuid() is concerned with uniqueness NOT unpredictability.

If an attacker can predict what the set of possible uuids will be, the attacker can flood the server with bogus posts having likely ids as predicted by analyzing the uuid() algorithm. Note that an attacker can confirm their ability to predict the id by generating their own posts.

If the attacker targets a table that is likely to have a large number of new entries, the change for the attacker to have a successful collision increases.

Fundamentally, the client should never be trusted with the ability to select anything that effects how things work.

Posted in technical.

8 comments

By pat – July 31, 2014

In praise of Javascript’s undefined

One of the unique[*] features of javascript is two different ways to represent ‘no value’: null and undefined.

[*] = unique as many popular languages do not have both null and undefined.

In my years and years of programming Java, I always missed not having a way to represent the ‘not value YET’ condition.

null always end up being needed to represent the ‘no value’ condition which made it difficult to handle the ‘no value YET’ condition.

‘no value’ is a definitive terminal condition: there is no value available. Period.

‘no value YET’ means the information is still being retrieved/calculate, a non-terminal condition. The requestor should ask again at some future date.

The ‘no value YET’ condition occurs frequently in internet coding. For example, server A initiates a request to another server, server B, for some information (V). V could take seconds to arrive or may never arrive.

The code on server A wishes to continue to run while waiting for server B to respond with the value of V. What value for V should be used for the server A code that is asking for V‘s value? In an idealized world all the calling code uses concepts like Promises and Futures and the problem is kicked upstairs.

In the real world, often times this doesn’t work in practice:

  1. This change almost certainly requires changing the contract about the object/value being returned. Every caller would then need to be changed. Often times this change will cause ripple effects that extend through massive amounts of the code.
  2. external libraries are not designed to deal with the complexities of getting V they just want V.
  3. Maybe V is part of a larger calculation where some value of V must be used. The caller supplies defaultV if there is no V. But the calculation involving V should be skipped if no V is available.
  4. Callers have their own timing constraints and may not be able to wait for V to arrive.
  5. the caller is happy to use a cached value of V even if Vcached is expired.
  6. exposing the details of the V being ‘on its way’ is too much information for the caller. The caller doesn’t have any alternative path available
  7. returning a value that is some type other than the return type expected by the caller is breaking the function’s contract with all the existing calling code.
  8. Lastly, leaking the implementation details of getting V means that if those details change all the callers are impacted.

This is where the beauty of null and undefined come into play.

For those callers that just need V today, null and undefined can be easily tried identically:

var V = undefined;
console.log( V == null );
console.log( null == null );

both return true.

so ….

if ( V == null ) V = defaultV;

Which is the same code the callers previously had. Thus, the vast majority of the existing callers continue unchanged.

For the minority of callers wanting to know if they should come back for the final answer:

V === undefined

will give them the answer they need.

Posted in software design, technical.

No comments

By pat – July 17, 2014

Code review #10: No emailed code questions

[Update #1: below is added in response to Hersh’s comment]
Developers have this:

Yet developers are (should be) willing to spend time explaining the code to new developers. Including emails and chats conversations, in-person conversations, etc.

I don’t insist on arbitrary mounds of (unnecessary) comments. Rather I want minimal comments (once again read this previous post about commenting the “why”)
[/update #1]

However when the questions do come up, developers I work with are not allowed to ask in person, NOR chat, NOR email me questions about specific pieces of code.

Instead, they must ask their questions as comments in the code. I will reply as a comment as well.

For example from production code:

// TO_KOSTYA why are we getting nvr records?
// TO_PAT this is because we create FILTER_BY_CATEGORY message end point records, for every broadcast envelope. So a message endpoint record is created for every endpoint, even if a message never goes in there. Such records are never posted to external services, which results in the externalEntityStatus to be returned as 'nvr'.
// TO_KOSTYA : we need to filter at the server. Those records are essentially a server implementation detail that clients should not see.
if ($envelopeStatus['externalEntityStatus'] == 'nvr') {
continue;
}

This technique has huge benefits:

  1. Other developers will see the conversation only if they care about the conversation (i.e. they are debugging something that passes through the block of code with the question)
  2. The thinking/reasoning that would normally be lost and buried in the mass of email is preserved for others – including new developers that show up months or years later.
  3. No speculative commenting: Developers writing the same text that they would in a chat or email and in the process are commenting code that is the most troublesome/confusing and needs commenting the most.
  4. If the underlying issue is resolved, then the comment block can be rolled up into a coherent more generic comment.
  5. Decisions about what should NOT be done are also captured right where an uninformed developer is likely to reintroduce a bug

As to my no chat/no in-person/no email rule: I am naturally flexible (we do have to get work done after all) about this with the requirement. However, the person asking the question must:

  • take the chat log and put it as a comment in the code
  • OR create a comment that would have answered their question if they saw the comment.

Notice what is happening, instead of putting developer time into an email exchange, the same effort is being put into the comments:

  • Developer time is unchanged,
  • the text is unchanged,
  • only the location of the conversation is changed.

Posted in code review, self improvement, technical.

2 comments

By pat – February 12, 2014

Ask for code samples, skip the coding tests during the interview

I always ask for code samples when interviewing a new technical candidate. I rarely ask for people to code during an interview.

Asking people to code well can easily become an exercise in how well they have a language memorized. Quite honestly, I have forgotten bits of languages that I no longer need. I am occasionally surprised, a few days ago I helped another developer by remembering about ‘cpp’. [1]

A code sample shows a candidate at their best (or worse):

  • They have time to do the code right.
  • Google is at their disposal.
  • They can test the code.
  • Do they comment?
  • Do they use meaningful variable names?

The code sample allows you to avoid mental traps:

  • The smooth-talker
  • The pretty face (both sexes)
  • The “everyone else liked the candidate” conformity

With 5 minutes or less to code a solution, you get sloppy code that does not reveal their true ability to code.

If someone’s sample code is pretty much as good as it gets for them. Ugly sample code means ugly code in *your code base* if you hire them.

A simple test to see how good that Java developer is.

Another question developer candidates

Below the fold for a real sample of bad coding. Can you find the issues?

[1] (cpp is the standalone program that C uses as its preprocessor. Running cpp allows you to see the post preprocessing text to be sent to the C compiler)
Continued…

Posted in management, technical.

No comments

By pat – October 21, 2013

The Dangers of Knight in Shining Armor and Princesses who need them

Some women want a Knight in Shining Armor to sweep them off their feet to rescue them.

It all seems very romantic. Except, that the princess in the story usually is insecure, helpless and dependent.

Fairy tales aside, helpless women are exhausting, needy and emotional dangerous.

My best friend in High School recently killed himself. Tom spent over 20 years trying to save a girl with low self-esteem as a result of parental abuse. He sacrificed all his potential (and he was quite smart – CalTech student). In the end, she is living and he was destroyed.

There is a good reason for therapists and lifeguards. Both are trained to rescue others without becoming a victim themselves. Unless you are one of those, attempting a rescue potentially results in your own destruction.

I understand bouts of self-doubt, suicidal thoughts, depression, etc that we go through. My own SO has weight issues. But the low-esteem issues are narrow issues. In other parts of her life, she is confident and successful.

Global self-esteem issues need professional help. In the end, the person with self-esteem issues needs to know the path to raise their self-esteem.

For example, if you are insecure at work: why are you insecure? Find a way to have small successes to counteract those doubts that you can use to remind yourself in the future of your competence. Don’t ask others to validate your competence – they might have reasons of their own to put you down.

Lastly, remember you get what you attract. Insecure people attract insecure people or people that prey on insecurity. The princess can be the victim of the Knight in (not-so) Shining Armor

Posted in self improvement.

No comments

By pat – October 20, 2013