poutine

I've worked for a very long time in software, network infrastructure and now Internet payments (complex stuff too) and mobile.

I've never heard a manager or developer say: If only we had someone that could write an algorithm to solve this travelling sales person problem we'd be saved! No. Inefficient algorithms are often good enough, typical programmers muddle through and yes pick up a textbook or reference wikipedia once in a while.

Modern software is a complex tangle of standards, protocols, and technologies. To build a typical example modern web application you're going to need to know linux administration, database administration, some server side language (ruby), a web framework in that language (ruby on rails), javascript (perhaps coffeescript), html, css (less), message queues (redis, beanstalk, etc), caches (varnish), loadbalancing proxies (haproxy), SSL termination, web application firewalls, network firewalls, providing JSON REST API's, Mobile optimization, real time communication (socket.io), third party API integration, Amazon S3 management and scaling. Etc.

All of this lifts the benchmark for what is an acceptable web app. The list goes on, and new bits keep getting added every year along with expectations.

It's bloody hard to find people that can deal with a majority of the above technologies. If you find someone that can do the full stack they're gold.

You want to be valuable? Prove that you're someone that can develop within modern software stacks and more importantly adapt as things change. Because change is coming, the music hasn't stopped and we're in for one hell of a ride.

Absurd. This has nothing to do with what I like or not. The facts are that Taiwan is not Hong Kong, Taiwan is a separate country who's future may or may not involve becoming part of China and that Foxconn is a Taiwanese and not Chinese company.

Smart phone? I agree smart phones are different. My somewhat glib inference was that the iPad could maintain the same market dominance as the iPod Touch due to similar reasons.

Just like what happened with the iPod and iPod Touch, right?

Foxconn is Taiwanese, if you think they care about their 'domestic buddies' you'll be sorely mistaken. Even if it were mainland Chinese they'd not give a damn about China's domestic industry over making stupendous amounts of money from Apple.

Despite the short term confusion of the name change (Not "iPad 3" just "iPad") it does make sense. Afterall you have iPod Touch, Macbook, Mac Mini, etc. Better than eventually having iPad 7, etc.

Wouldn't be surprised to see the iPhone 5 just be called the iPhone.

His rant doesn't seem too informed: "aggressive anti-performance and apparent contempt for the web by Twitter’s designers"

According to his charts most of Twitter's page is JS/CSS and presumably set to heavily cache. Very little is data. Once you've done the first page load Twitter's pages will load quite fast and efficiently. While quite a lot of JS, this is good design, not bad.

The facility isn't lost nearly as much as one thinks. And the joke is on the younger people, seriously.

Whether the data is sent via HTML or JSON it will still incur the network latency.

Pretty cool that the Xoom has a barometric sensor. Other than this nifty use case what is it used for?

Another suggestion for tuffmail. Used them for years. Stable and does what you need.

Doesn't look it supports server sent events, a pity as they're much nicer to deal with than websockets (which it does support unlike the native browser). Still going to be a long time until we can depend on these technologies for android as uptake on chrome is going to be slow.

HTTP PATCH was created due to this problem, though I've not run across an API using it yet.

http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-...

That may be so, however he asked what else is wrong with this API. An ugly URL scheme is something wrong with an API in my opinion and lots of people agree (see Rails, etc).

It's pretty straight forward, just do the following:

- Use HTTP verbs: GET to retrieve one or more objects, POST to create a new object, PUT to update an existing object, DELETE to remove an object.

- Address objects by collection and by individual object: /users/#{user_id} is a specific user you can PUT, GET or DELETE. /users is where you POST to in order to create a new user.

- Use HTTP codes to return the result back to the client (ie HTTP 200 when you get an object, 201 when you successfully POST an object, 404 when you try to GET/UPDATE/DELETE an object that doesn't exist).

- I find it good form to return objects in JSON with the type of object at the top of the data structure, ie {:users => [ #array of users here ]} or {:user => { #single user }}

- Use OAuth or some sort of token system for authenticating the calls, don't use HTTP Auth.

You can get pretty anal about things but if you follow the above you'll have a cleaner API than 90% of the API's out there.

From a quick glance:

- Doesn't use HTTP verbs (GET, PUT, POST, DELETE) to retrieve, modify, create and remove objects.

- Doesn't use a restful url path to action on (ie. GET /users/#{user_id} to get a specific user by id, POST /users to create a new user).

- Doesn't use HTTP codes to return results (ie. HTTP 200 for normal operations, 201 for created, 40x for error conditions).

Indeed it's much easier if you're proficient in both.

I've written a number of non-trivial IOS apps that are heavily server based. I've done both the server side (Ruby Sinatra API App, MongoDB, Varnish) and the client side (Obj-C naturally) and consider myself equally proficient in both.

The client generally takes much longer to write and debug than the server due to all the little issues with having a smooth, non blocking UI, network availability, juggling data and managing resources that you have with the client app. Not to mention any custom UI controls you make.

Indeed it's worth pointing out that solar energy kills far more people than nuclear power does in the west.

Installers fall from roofs quite often...

While an impressive engineering feat, this probably isn't equal to a similar sized hotel in the US.

Having lived in a new and quite upscale (rent was 8K RMB/mo, apartment sold for $500k USD) Chinese apartment in Beijing for a couple years and visited many others I can attest that the build quality is absolutely awful. The stuff they're building will not last. Buildings in China are built for instant gratification using the lowest skilled labour available with fit and finishings that only look good from a distance.

This is why PPP GDP adjustment is such BS. The argument goes that you have a skyscraper in Shanghai and one in New York you have a skyscraper's unit of wealth in both places, though the one in Shanghai costs half as much to build. Therefore you double the GDP gor China (figures for illustration) in order to account for this purchasing parity issue. Problem is, that the skyscraper in Shanghai will last a fraction of time that the one in New York does. China is the land of McMansion skyscrapers.

Agreed, this sort of thing harms any sort of boycott by making things look ineffective or perhaps less effective.

I know that for the 40 or so domains I transferred off of Godaddy none of them used Godaddy's nameservers. Indeed it's ill advised to use your registrars nameservers.

I would encourage you to take this analysis down less it get picked up by conventional media.

I believe the term he's looking for is pedantic.

pushes glasses up on nose

Similar issues in dealing with the IOS SDK, ended up removing support for single sign on in my app due to it simply not working part of the time.

Indeed this is precisely how I do things as well. If I have a custom UIView subclass then I still lay it out in a xib in relation within it's superview. Doing it this way makes refactoring so much easier.

In dev teams UI done in an xib will make the UI easier to understand. It's also much faster to do many things with the GUI.

If you did this then in IOS 5+ you'll be missing out on storyboards which are a great productivity improvement. Not a good idea. Indeed you don't want to use IB all the time, but you should learn when to use it.

Congratulations Reddit. Boycotts do work!

Just transferred 40 domains off of GoDaddy using this. Thanks.

Any such group for Vancouver?

Very hard to find experienced Ruby devs in Vancouver, Canada. Have had open positions for months at my company with only junior people applying.

Bullshit.

http://www.telegraph.co.uk/technology/htc/8749797/HTC-uses-G...

Commence the downvotes.