nupark2

The money is nice, but after watching the ridiculous waste of PHP idiocy for the Nth time, you can't help but want to get people to stop.

C is enormously more consistent, better defined and specified, and well-documented than PHP.

It's a solid enough language with a very specific use case, and not even remotely competing with PHP.

PHP is a terribly inconsistent, poorly defined, poorly documented, poorly implemented, poorly designed language that can't do anything better than any of the other languages it is competing with.

The one thing PHP has going for it is inertia. That's it.

There's almost no room for that kind of content from a photo sharing system.

You can't trust them all equally, and allow for a failure in any one of them to result in a total failure of all security. That's the M&M security model -- crunchy on the outside.

This is one (of several reasons) I wouldn't use memcached without authentication if it could lead to a privilege increase: It completely breaks defense-in-depth. Compromise of just one system can lead to total system compromise.

You're just moving the costs around, and likely transmitting far more data than needs be sent.

In addition, you're front-loading the transmission of data that users don't need right now.

Having built many network-facing mobile applications with exceedingly large user bases, I'm unconvinced. The maintenance complexity, the excess transmission of data, issues of data consistency over time, the lack of integration with client-side business rules without considerable investment in code that significantly replaces the sync logic.

I think that the reality of the situation is that in the rare cases you need offline, fully synchronized data, it's not particularly difficult to just download what you need as an atomic unit and save it. The majority of the time, however, on-demand request handling is more efficient, well-defined, and maintainable.

Additionally, the contractor has to set aside sufficient profit to cover the risks involved in short-term work. Business development takes a considerable amount of time, and it can be days (or, in some cases weeks) before another contract starts. That time has to be paid for.

The focus client-side is on speed, battery-life, ease of programming, and perhaps most of all, maintaining separation of concerns between the server-side data model and the client data model. The server must be free to evolve independently of the client, and many remote clients will run legacy versions of your software for extended periods of time.

Moreover, rarely is data distribution sufficient to model high-level interactions between client and server, which is more likely to introduce bugs, complexity, and significantly detract from the long-term maintainability of the client/server protocol.

The end result is that you don't particularly benefit from CouchDB client-side, and especially not replication -- you need a well-defined supportable network model.

1) The file system correctly orders or journals operations (I'm not familiar with XFS, but this is the case with FFS2/FreeBSD, ZFS, ext3/4 journaling, etc).

2) The database system correctly orders or journals operations, and properly fsync(s) to disk (which postgreSQL does)

Of course, there's no harm to an abundance of caution with something like this.

We're on a long, slow slide away from CS and towards hacking out yet-another poorly designed programming language/web framework/whatever, patting ourselves on the back for re-inventing the wheel, and then grabbing some beers.

I'm studiously unimpressed with the quality of candidates, technology, and culture that I've been seeing in recent years.

Unsuccessful copies may demonstrate that the barrier to entry is high (for whatever reason), and may in doing so still improve the efficiency of the market. Likewise, a failed clone may simply demonstrate the copying entity's inability to compete.

Regardless, I don't see how attempts to copy (and improve?) are a bad thing for the market.

I think the fact that you've developed a native app here provides sufficient falsifying evidence for this declaration.

When looking for the optimal (for the user) solution, the decision as between a web site or a native application should be made on the basis of user requirements, and the solutions that best meet those requirements, not based on the technologies that you, personally, are comfortable with.

If you ignore an organization's existing investments in web engineering and web-focused infrastructure, webapps aren't empirically and objectively easier or cheaper. Rather, they're a mechanism by which an organization can leverage money they have already invested in building a web-centric team.

I see this as a temporary state, initially caused by the rapid adoption of the web, and will ultimately disappear as more broad, less web-centric development experience and infrastructure investment becomes the norm.

It doesn't solve retain cycles, thus requiring the judicious use of __weak in cases where a retain cycle may emerge. Determining where such a cycle may occur requires understanding reference counting. This significantly impacts your expression of algorithms where the simplest/best implementation may involve cyclic object graphs.

Additionally, ARC does not handle mixing CoreFoundation and Foundation code directly, requiring one to manually express bridging rules based on an understanding of reference counting.

It may be that ARC gradually smooths out its rough edges, and we find ourselves in a situation similar to GC, where developers need only understand the difference between weak and strong references, and the opportunities that exist there for leaks caused by maintaining strong live references.

However, we're still a bit far from that point, and newcomers should remain well-aware of retain/release and the vagaries of reference counting systems.

Company network with company devices: sniffing traffic is fine, insofar as it's done by configuring the devices with a private CA.

Company network with personal devices (including visitor's devices): silently MITMing SSL using forged certificates and a real CA is not fine. They can either forbid the use of personal devices, or request that I install their internal CA.

Yes, just don't do that. There are sufficient mechanisms to distribute security policy configuration to company devices.

Silently sniffing traffic from external, personal devices is unequivocally unacceptable. I would be livid to know that a company was silent pretending to be my bank, my e-mail provider, or even just Amazon without my prior consent. Having to explicitly trust their internal CA is exactly how that consent is supposed to be provided.

The CA system's trustworthiness is fundamentally broken. I am austounded that Mozilla did not immediately remove the CA certificate from the trusted set.

As far as it being a hack for a closed platform, I'm not sure why that matters if your goal is to interface with the primary mobile phone platforms. This solution works, and if you need something more professional, working with the dock connector itself isn't an burden any more insurmountable than dealing with injection molding or other product design and manufacturing concerns.

That aside, it seems a bit ridiculous, given that we already have sockets, to bolt on a protocol that exists almost solely to work around security issues involved in a browser opening a socket.

The course offerings are generally constrained, and the courses themselves are often lightweight versions of the university course -- assuming that the subject you want is covered at all. The facilities for continuing education courses are also often less robust.

Take CCA in San Francisco. This is a highly considered arts college, and they offer a small number of introductory extension classes:

http://www.cca.edu/academics/extension/courses

Compare to their full course offering:

http://www.cca.edu/academics/undergraduate

You'll have to drill down on individual categories to explore the full breadth and depth.

Continuing Education offerings are rarely a substitute for the quality of courses they offer to a matriculating student.

Given how often educational institutions have raised their tuition in recent years, I'd love to see them institute a program where they charge a (possibly large) fee to allow non-matriculating adults to audit a course, without limitation or requirement, and use those fees to subsidize enrolled student tuition.

However, this may be a shift too far in the "trade school" direction for their comfort.

The "continuing education" programs that do exist are generally stunted and poor.

Would it be so terrible if I spent 10 years gradually taking classes in engineering and sciences, perhaps never earning a degree? Why is college something you do only once, when you're arguably too young to genuinely appreciate it or even know what you want?

This is why I find Khan Academy to be so fascinating.

Khan Academy allows me, with no overhead whatsoever, to pick (or refresh a skill), whenever I want. If my math skills aren't up to snuff for a hobby project I'm working on, Khan Academy is there. If I can't remember how a transistor works ... Khan Academy has me covered.

Compare this with the incredibly high overhead of high school and 4 year degree programs. If I just want to take a refresher engineering class at the local University or Community College, I have to go through the full admissions process, provide a full academic history, justify my reason for being there, and then work at a preset pace and on someone else's schedule. If I'm stuck at the undergraduate level, I have to take a slew of general ed courses totally unrelated to what I actually want to do.

Contrast this with frictionless learn on-demand education.

There are, obviously, downsides:

- Not all topics are covered.

- The depth of coverage is not on par with a university education.

- No access to very expensive university equipment

- No one-on-one access to a professor

- No student discounts on expensive software

Despite those downsides, the format has worked great for me.

In my ideal world, formal K-12 and college education would be comprised of:

1) Elective projects that rely on a broad swath of skills.

2) Courses to be taken in concert with the projects to provide requisite skills, as those skills become necessary.

DNSSEC and SSL further reduce this attack surface.

The ISP doesn't need to do anything specific to support it.