ocskills

This comment extends further into the realm of speculation than the original post. The article doesn't even mention Apple's understanding of encryption, let alone specifics like algorithms and key sizes.

The post only speculates about the meaning of Apple's carefully worded feature description, the scope of the device encryption, and whether it's primary intent is to enable the remote wipe feature.

With regard to four digit pins - the strength and length of a password is hardly immaterial to security if it is being used to derive or encrypt the key. This is especially true if the wipe needs to be triggered remotely. Storage of the key on the network or MobileMe would present a host of other issues that I suspect Apple would want to stay away from.

"They will embrace MySQL and Open Source and put their technical expertise on it to ensure that MySQL continues to be the most popular advanced Open Source database."

That distinction rightly belongs to PostgreSQL: http://www.postgresql.org/about/

You're misreading the article. The problem has to do with uncoordinated breaking changes to a public API. There were no problems for our apps.

Let me draw an analogy: imagine that one day before release MySQL (or pick your favorite DB) decided to deprecate and ignore the the greater than > operator on queries. No errors - it would just pretend that query clause didn't exist and return all rows for queries that used a >. How would that affect your application?

The point is that when you expose a public API it becomes a contract with your developer community. If you make a breaking change to the API you have a fundamental responsibility to effectively communicate the change and ensure that it doesn't create massive and unpredictable results for clients. In this case Twitter didn't do either.

"You have a dog, and I have a cat. We agree that they are each worth a billion dollars. You sell me the dog for a billion, and I sell you the cat for a billion. Now we are no longer pet owners, but Icelandic banks, with a billion dollars in new assets."

What a wonderfully simple explanation of mark-to-market!

The future is here already, and has been for decades.

These non-relational database structures are not a new or revolutionary idea. The same concepts have long been implemented in systems like LDAP, X.500, and document-oriented databases like Lotus Domino.

The real mystery is the recent trend towards completely reinventing the wheel. For instance, LDAP (the protocol) is incredibly efficient, standardized, and well supported on most development platforms. It provides a standard query / filter language, facilities for scoping, and data updates. There are standardized exchange formats, wide availability of OSS and commercial management tools, and multiple server implementations.

Yet, there seems to be a great interest in developing from scratch highly proprietary and non-portable alternatives that do exactly the same thing (or less). These systems ignore decades of research and lessons learned through practical implementation.

The real issue though is that direct comparison of the two models is inherently flawed. They each have their own strengths and weaknesses, each excelling in situations that the other falls short. Looking at them as complementary models is perhaps a better approach.

ASP.NET is a very flexible environment but, like any anything, it takes time to learn. You can tweak view state settings, manipulate caching, tune sessions, adjust markup, and exercise fine control over web control settings.

The fact that most novice developers won't know how to do these things without a learning curve is not the fault of the framework.

In fact, most of the observations the author makes here are equally applicable to other "quick start" programming environments. For instance, I'm sure there are plenty of bloated and poorly implemented Rails apps that resulted from inexperienced developers hacking up applications generated 100% by scaffolds.

I think there is a big difference between the two.

The FSF uses copyright assignment to ensure that open source code is not legally encumbered.

MySQL uses the copyright assignment so they can sell code contributed by open source developers in their commercial platform without compensating the authors.

Of note, Sun ironically performed a benchmark between PostgreSQL and Oracle. The results were that PostgreSQL performed very closely to Oracle under several scenarios.

http://it.toolbox.com/blogs/database-soup/postgresql-publish...

It's not a direct comparison between MySQL, but Oracle is highly regarded from a performance standpoint.

Feature wise, I don't think there are many things that MySQL can do that PostgreSQL can't given a proper configuration. The main difference is that PostgreSQL doesn't include things like clustering as part of the core distribution like MySQL. They are often released and maintained as third-party add-ons to the core platform.

For instance, PostgreSQL has a number of projects that facilitate clustering. Slony-I is a stable open source replication framework (http://www.slony.info/). PGCluster provides a multi-master replication facility (think Oracle RAC). PGpool allows front end load balancing of connections.

It's the act of developing a business plan that is important, not the plan itself. There is also much more to a business plan than just projecting revenues.

If you are realistic, planning forces you to actually think critically about things like startup and ongoing costs, cash flow, suppliers, sales pipeline, time/resource requirements, the window to achieve profitability before you run out of money, and most importantly the critical steps you need to take before you start.

After you're in business the game changes. Then it becomes much more about flexibility and adapting to new information and changing situations. There is no doubt that if you blindly stick to a plan no matter what your business will fail, but this doesn't discount the value of the up front planning process.

Paypal and Google Checkout are both good alternative options to look at. In some cases when you factor in all of the upstream credit card processing charges you'll even pay less.

Hiring salespeople purely on commission is tricky. It shifts all the initial risk to the side of the salesperson. Therefore people willing to work that way often want a big slice of the revenue and aggressive payment terms. While the lack of up-front risk for your company is nice, the commission terms can come back to haunt you if your product / service becomes successful.

I'd take a serious look at Braintree for credit card processing http://www.braintreepaymentsolutions.com/. I'm not affiliated, we're a customer that uses them for processing. Reading stories like this, I'm glad we do.

When we signed up they gave us a heads-up on almost every one of these facts (i.e. warning us up front to authorize a minimum of a dollar or many banks would reject it). They called AMEX on our behalf to get the service hooked up so we didn't have to. They've also given us tons of technical advice, like how to improve accuracy on AVS checks and details on what some of the esoteric failure codes really mean.

Autonomous and dynamic resource allocation built on a message queuing system. Could team at Twitter benefit from a chat with the folks at SmugMug?!

I hear what you're saying with regard to clients, but I think you totally missed 37s' point. They're NOT saying "don't mockup at all". Rather, they are encouraging an interactive process with real and usable output that adapts more easily to collaboration and change. There is nothing you can do with Photoshop that you can't do with paper prototypes and follow-on HTML mockups.

$3 for a site really isn't that bad, all things considered. It's less than many image downloads on istockphoto.

Agreed on all sides. The gap between decent and really good designers is huge and great designers are no more a commodity than great programmers. If the author can find a great designer to work with I'd strongly recommend he does. If not, and he's doing it himself, he needs to keep things simple if he's going to produce passable designs.

It's sad to hear he passed. Genuinely fun fantasy novels are hard to come by, but were Robert Asprin specialty. I grew up reading the Myth Adventures books, and amassed most (if not all) of the collection. Then I moved on to Phule's Company, another great series he wrote. I'm looking forward to sharing them with my son when he gets a bit older.

"corporate companies look for money and large numbers of staff. Web development agencies on the other hand look for quality, code is poetry."

This is a very naive statement. Web dev agencies are looking for the same thing as corporations: to make money, and maintain size or preferably grow. They are just smaller and earlier in the business lifecycle, which means less bureaucracy. Many cater to larger corporations anyway, and face the same political challenges by proxy.

The bottom line is that work experience will depend on your team much more than your company. There are just as many tight knit and creative groups who their love code poetry at big companies as at small.

I'm actually a developer and I have to strongly disagree with this comment. The same gap exists (http://www.joelonsoftware.com/articles/HighNotes.html) between good designers and mediocre. In my experience, great designers are far from a commodity. I also agree with the other poster who said "Think Google not Microsoft". That's great advice - with a little practice even a programmer can produce decent designs if they keep things simple and don't try to get fancy.

Everyone's always talking about the need for a new mobile social network, but one already exists - it's called Twitter. It completely sidesteps the fact that most mobile browsers suck (iPhone nonwithstanding) by building the platform on text messaging as the lowest common denominator.