Archive for February 2012
If I had one bit of advice to someone thinking of a startup—including myself, at times—it would be this. Solve a genuine problem, even a trivial one, that you actually have, and that isn’t being adequately solved by an existing solution. Then think about how you can get money for solving that problem. Be wary of scenarios in which your revenue base and your customer base have no overlap.
If I had a second bit of advice, it would be this. Is the elevator pitch for your new startup—no matter how sincerely you believe in its fantastic future—at its heart a variant of, “Think [well-known service name] but with [added feature or new twist]”? If it is, you’d better know somebody willing to call bullshit.
[Seems like right fine advice...]
Source: Coyote Tracks
At first read I agreed with Cross completely, but you know, there’s still a lot of successful products out there that don’t provide a good user experience. Apple is successful by (mostly) providing very good UX and that’s certainly influencing the current generation of designers, but it’s not the only path to success—and there’s an awful lot of work influenced only by Apple’s superficial aesthetics.
[In the end… it's not about aesthetics. It's about making tasks easier to accomplish. And about understanding what people were trying to do when they did something and being smart about how you react to it. the aesthetics are the final piece to a very complicated and difficult puzzle. ]
Source: Coyote Tracks
Particularly powerful are the newly-released copies of the IBM concentration camp codes. IBM maintained a customer site, known as the Hollerith Department, in virtually every concentration camp to sort or process punch cards and track prisoners. The codes show IBM’s numerical designation for various camps. Auschwitz was 001, Buchenwald was 002; Dachau was 003, and so on. Various prisoner types were reduced to IBM numbers, with 3 signifying homosexual, 9 for anti-social, and 12 for Gypsy. The IBM number 8 designated a Jew. Inmate death was also reduced to an IBM digit: 3 represented death by natural causes, 4 by execution, 5 by suicide, and code 6 designated “special treatment” in gas chambers. IBM engineers had to create Hollerith codes to differentiate between a Jew who had been worked to death and one who had been gassed, then print the cards, configure the machines, train the staff, and continuously maintain the fragile systems every two weeks on site in the concentration camps.
Newly-released photographs show the Hollerith Bunker at Dachau. It housed at least two dozen machines, mainly controlled by the SS. The foreboding concrete Hollerith blockhouse, constructed of reinforced concrete and steel, was designed to withstand the most intense Allied aerial bombardment. Those familiar with Nazi bomb-proof shelters will recognize the advanced square-cornered pillbox design reserved for the Reich’s most precious buildings and operations. IBM equipment was among the Reich’s most important weapons, not only in its war against the Jews, but in its general military campaigns and control of railway traffic. Watson personally approved expenditures to add bomb shelters to DEHOMAG installations because the cost was born by the company. Such costs cut into IBM’s profit margin. Watson’s approval was required because he received a one-percent commission on all Nazi business profits.
[In an odd coincidence, I was discussing IBM's role in the holocaust just this weekend. Thanks T., for the pointer to the article.]
Put differently, it’s understood that all software changes incur some risk, and it’s critical to be able to manage this risk on your own terms. Taking that risk in development is good because by definition that’s when you’re incorporating and testing software changes. On the other hand, if you’re shipping production software, you probably don’t want to take this risk when cutting a release candidate (i.e. build time) or when you actually ship (i.e. deploy time) because you want to validate whatever you ship.
You can address a simple case of this problem by only depending on specific versions of packages, allowing no semver flexibility at all, but this falls apart when you depend on packages that don’t also adopt the same principle. Many of us at Joyent started wondering: can we generalize this approach?
Redis ASCII art logo added at startup. This is where our major efforts went in the latest months.
[I love his sense of humor.]
The Rails master branch was moved to 4.0 two months ago, almost 6 years to the date of the announcement of Rails 1.0, and the primary cited reason for doing so is to get everyone using Rails on Ruby 1.9.
[I understand the lack of migration all too well. Some codebases require a tremendous amount of work to move forward, and may not be worth the investment from a business point of view. But at some point, that app either needs to be sunset or worked on. Now's the time to decide which category it fits into.]
Source: Union Station
Top and left navigations are typical on large screens, but lack of screen real estate on small screens makes for an interesting challenge. As responsive design becomes more popular, it’s worth looking at the various ways of handling navigation for small screen sizes. Mobile web navigation must strike a balance between quick access to a site’s information and unobtrusiveness.
[I haven't watched this yet. Noted for later.]