Coming from C++, protocols vs categories still mystify me a bit.
They appear to be methods for doing multiple inheritance type stuff without the multiple inheritance problems. From what I understand protocols set a list of methods that a class implementing that protocol must provide, whereas categories let you 'tack-on' methods to existing classes.
They seem like powerful features & I'm sure there is more to them than I've described, but I sometimes have problems re-wiring my brain to 'think in objective-c'.
Seeing more tutorials that show how to use these interesting language concepts in real projects would be very educational.
Protocols are "interfaces" (in the general sense of the word in programming). So they are useful when you want to write a delegate (or callbacks in the general sense of the word) class. Many classes have a delegate property that is of type id<SomeProtocol>. Equivalent to Java's interfaces, but Cocoa use protocols heavily for delegates only.
Categories are useful not for sharing code, but for expanding a class's functionality. This is especially useful when you write a class X that works with an existing class Y, but some of X's code should be an instance method of Y, or X introduces additional capability for Y to support X. UITableView adding functionality to NSIndexPath to support referencing table sections and rows is a good example. All those Java classes that add static methods to support existing Java classes, or if you used Smalltalk and added methods to existing classes, this is the equivalent.
>Equivalent to Java's interfaces, but Cocoa use protocols heavily for delegates only.
Uh, NSCoding, NSCopying and the million other non-delegate protocols? Cocoa uses protocols heavily for a lot of things, not just delegates. The average Cocoa/Cocoa Touch developer, however, uses protocols mostly for delegates.
A protocol says that an object can (and in some (but not all) cases, is required to) implement a given list of methods, leaving the implementation/the "how" up to the programmer. Think of protocols as being similar to interfaces in Java.
OTOH, A category says "in addition to the existing methods, this class will also, for sure, implement these additional methods — and here's how."
The article illustrates the well-known mantra "to survive, you must adapt to your environment".
In the IT industry, incrementally developing your existing businesses will quickly lead to oblivion. IBM succeeded in the transition away from the mainframe business, and thus IBM can be seen as an example what all the companies in the industry need to do to stay afloat.
I did not find this article a waste of time. It reminds me of Thomas Kuhn's view on scientific revolutions. Most of the time people try to solve problems by using already known patterns. Every now and then somebody comes up with a completely new idea; the new idea allows its possessors to solve the problems orders of magnitude better (i.e. faster, cheaper, ...).
It depends on the application(s) you wish to run on AWS. If your EC2 instance runs an HTTP server that is backed by an external database like RDS, your I/O bottlenecks is not the EC2 instance's disk.
The article points out rather successfully that once you know at least something about the internals of each AWS service, you can fit them into your particular needs.
We configure our production servers and push new releases there with Puppet. I like Puppet: its fail-safe and reliable.
There is, however, one thing I don't fancy in it. Puppet does not support insecure client–master communication. Requiring SSL communication is OK, but one should be able to switch it off if it brings no value.
We are running our our servers on AWS, and we rely solely on AWS security groups to grant and deny accesses. Puppet's SSL traffic brings no additional security to us; it only complicates matters. For example: we would like to shut down the Puppet master EC2 instances when they are not needed. However, this is not possible, since after start-up the EC2 instances have new IPs, and this breaks the Puppet-signed SSL certificates.
That's correct. The problem is that the EC2 internal IPs change even though the instance would have an Elastic IP. EC2 instances use internal IPs when communicating with other EC2 instances (this is a feature of AWS DNS). As a consequence, Puppet clients cannot access the master by using the master's Elastic IP.
That sounds rather inconvenient. Are the external elastic IPs non-routable internally? I mean, if you add the IPs explicitly to hosts files then will traffic to those IPs not work?
The article quite well describes some of the valuable features of a good login UI.
The login page is (often) the first place a user encounter your site. If that page creates a sense of repulsion in the user or forces him to struggle, the user is probably left with a feeling that your site is against him. That's not something you want.
Its not difficult nor time-consuming to implement a proper login UI. However, surprisingly many sites don't pay enough attention to it.
Jeff, are there any plans to support mailbox provisioning?
At the moment I'm using Rackspace's REST API to create a mailbox for our new customers. I like their API, but I don't like the fact that we have to communicate with their IMAP and SMTP servers to receive and send email. It forces us to write a lot of bug-prone email handling code.
