jcizzle

JSON and Erlang just don't get along in the way you'd like them to, unfortunately. Some of that has to do with how Erlang handles (or doesn't handle) strings. Some of that was that there was not a data structure that closely mirrored JSON's structure in Erlang up until Maps were introduced.

The problem isn't really JSON - JSON is an exceptional format for what it is supposed to do - the problem is that Erlang was created for a specific purpose and that purpose wasn't to vend out strings/JSON over HTTP.

The hungover table is just a list of the day after drinking holidays: NYE, St. Pattys, Memorial Day, Thanksgiving, Christmas/eve. Since those days skew the 4 day monthly total that much, I don't think we are being told anything too meaningful. Pretty neat visualizations, though. Would be cool to look for other events that dictate this data.

You can also define methods without labels:

- (void):(int)arg :(int)anotherArg :(int)someArg { NSLog(@"%d %d %d", arg, anotherArg, someArg); }

[self:1:2:3];

Try it. It compiles. It runs. How great is that? In fact, even Apple has done this!

+ (id)functionWithControlPoints:(float)c1x :(float)c1y :(float)c2x :(float)c2y;

So does this make this the best option? Should we even name our methods?

Of course, that is silly. Naming our methods appropriately tells us a lot. It means we don't have to check the documentation as much, which means we can effectively write faster. We're communicating with our code and our teammates more efficiently. The same holds true for explicitly typing method return values.

So ask yourself this: what's the default storage mechanism for a property, assign or strong? Now what was it when ARC first was developed? That's right, it was different. So you could see how someone might be confused reading your code if you weren't explicit. They might spend time looking in the wrong places for a bug. So why not be explicit? It's not about you, it's about everyone else who is left with your code.

So Brad Cox doesn't explicitly type his returns. Neither did Nextstep sometimes. That was 20+ years ago. We didn't have fancy IDEs with autocomplete; keystrokes were a luxury. That's probably why they couldn't put the 'e' on 'creat' in libc.

Last couple of Objective-C articles making it to the top of Hacker News have been bad. Just a kind warning to any budding Objective-C developers: just because it made it onto Hacker News doesn't make it good.

I'm not seeing the same thing. The big chunk of red on the south side of the city is the ATL airport. ("Checking in! #delta #hartsfield) Georgia Tech, Downtown, Midtown, VaHi, Morningside, Druid Hills, Buckhead, Brookhaven, Marietta, Lake Claire, west side of Decatur and the south end of Sandy Springs are the areas I see in red here. These are all wealthy areas. All along the northern perimeter - which is mostly just white-collar businesses, is mostly red tinted and all along the rest of the perimeter is green. Other than Hartsfield Jackson, there is a pretty solid cone of red emanating from downtown into the north. I would say this is 100% spot on with mapping wealth to iPhones, although, I am not sold on the numbers that generated the map.

Two different styles of competitive play my fiancee and I tried:

1. You can spin around, you can't move and you can't Google. 2. You can spin around, you can move, and you can Google - but you only have 10 minutes for 5 guesses.

How are you performing this test? Are you creating an application with a plain grey window and running it?

I think this could be an OS issue/graphics driver issue. I sometimes notice things "behind" my dark grey Xcode editor window - like for example, I can see this website in Safari behind Xcode. However, sometimes, I see stuff that isn't directly behind Xcode - but it is in another Space.

If the hardware test is succeeding, and you are only seeing "ghosting" on particularly colored windows, I think it is safe to say it may not be the display. (It still may be the display. I'm just saying there are more variables here, and I don't have all of your information.)

Good point, although, an experienced Objective-C developer can already write iOS apps - learning Ruby in the context of backend development would probably be more beneficial. It'd be like asking Michael Jordan to play basketball left-handed instead of playing baseball.

Well, here are two short snippets on how to do that. It is incredibly easy. (Sorry, I couldn't find a better paste it host.)

http://paste.org/53022

This fear of learning a new tool, language or API boggles my mind.

The insight alone from seeing a new corner of the programming world is worth biting the bullet and learning something new.

Injuries are a part I hadn't thought about. Common injuries in that part of the body are: shin splints, achilles issues, plantar fasciitis, calf pull, compartment syndrome, and stress fractures.

I know of at least two athletes for each injury who have either missed training time, an entire season or a career. Injuries are incredibly common in track and field: and make no mistake, there is no emotional-movie-style strength that allows an athlete to overcome their injury due to sheer force of will. Track and field is an 100% sport: if you aren't at 100%, you aren't going to win. A lot of the sport is managing and preventing injury, especially at the elite level.

While I would reason that "upper leg" injuries like hamstring, glute, hip and quad pulls are more damning and common than "lower leg" injuries (especially among men), and that upper body injuries like arms and abdomen are nearly unheard of, being able to write off an entire class of injuries is a huge bonus.

I also didn't mention strength over time benefits: the ability to have a consistent power output of a critical part of your stride (the toe push) that is unaffected by fatigue is very helpful.

I think some of the comments are missing an understanding of sprinting, so I will attempt to clarify:

There are four "pure" sprinting events, 60m (indoor only), 100m (outdoor only), 200m, 400m.

On TV, you just see a person effortlessly "sprinting." However, the sprints are actually very technical events. What you don't see is that each race is comprised of four phases: beginning with an explosive start out of the blocks, a drive phase, a transition phase, and finally a sprint phase.

The drive phase - which some commenters have concluded as Pistorius' weakness - is where the athlete builds speed. It is characterized by a forward lean in the athlete and powerful, "pulling" strides. At the elite level, an athlete will remain in this phase for 30m-40m, depending on the length of the race and the height of the athlete.

As the athlete builds speed, it becomes much harder to stay in this forward-leaning position - their legs simply cannot keep up with their body. Thus, they begin to transition into a different style of running. This is called the transition phase - where the sprinter's body moves to from this leaning drive phase into the tall and upright sprinting phase. This can be anywhere from 10-30m.

The drive and transition are important. Some time during these two phases, the athlete will reach their maximum instantaneous speed. At no point after reaching maximum speed will the athlete ever reach that speed again. Thus, the race becomes "who can slow down the least."

The upright sprinting phase is where the athlete tries to maintain the speed they built up during the drive phase until the end of the race. An athlete will be upright, with the slightest of forward leans. Their legs are firing straight up and down very quickly, trying to minimize the time spent on the ground. The ability to do this correctly very much depends on an athlete's "sprint endurance" - which is a completely different kind of endurance than, say, running a mile.

So, on average, 90% of a 60m race is spent gaining speed, 50% of 100m race, 25% of a 200m race, and 12% of a 400m race. The race a sprinter chooses to run depends on whether they are powerful and explosive (shorter races) or how little speed they can lose while upright (longer races).

Here are two fun facts now that you know this information: 1. Marion Jones (who is a cheater) did not have the fastest top end speed out of her contemporaries. She did, however, have the best ability to maintain speed. She was a 100m Olympic Gold Medalist. 2. The Olympic-level weight lifters will outperform Olympic-level sprinters in the first 30m of a race.

There are some nuances to what what I've said that I won't bore you with (for example, some 200m runners can perform a mini-drive on the curve to grab a bit more speed for the straight), but the basic idea is that your sprint endurance is crucial in EVERY sprint race except the 60m. You can make your own conclusions about whether or not Pistorius is legit, but having run the 400m at a high level for a number of years, I can tell you that not being able to feel your calves or feet or have to use the energy required to make them move would have been something I'd be interested in.

iOS 6 was really the first major revision that didn't change anything fundamental that will force another edition of the book. So, everything in the book not only works with iOS 6, it is still the recommended approach/foundation.

Well I can certainly answer the iOS Development one with a shameless plug: http://www.amazon.com/iOS-Programming-Ranch-Edition-Guides/d...

I spend 8 hours a day in Xcode and absolutely love it. It has its rough edges - which you eventually learn how to circumvent - but most of these complaints seem to be misunderstanding more than issues with the IDE.

Reminds me of when I had to use Visual Studio for an extended period of time. I started off hating it, then eventually figured out how it wanted to play, and ended up liking it.

I wonder if authors of these types of articles come back to them a year later and think, "Gee, I sound foolish." Because that's how they sound to me now.

Selectors always describe exactly what the method does and what it needs. For example, stringByAppendingStringWithFormat: says "You will get a new string, by appending a format string to the receiver." There is also the mutable counterpart, appendStringWithFormat:, which is shorter because it doesn't return a new string, instead, appending directly to the receiver.

Verbose selectors make Objective-C self-documenting at the cost of extra typing. But autocomplete solves this problem because you only ever have to type 2-5 characters to insert the method you want (once you are experienced enough to predict what autocomplete will spit out).

Objective-C naming conventions form predictable patterns. Inexperienced programmers gripe because they have yet to figure out these patterns, good programmers love Objective-C because they understand these patterns and can therefore predict the name of a method and its arguments and great programmers write their own classes that use these patterns.

In one statement, you say that not all people make a choice about their bodies and in the next you say that people are sometimes sedentary because they work so hard in their field. Well - that's the choice. They choose to spend all of their time working and none of their time exercising.

Working hard at your job is great, but a lot of that is habit and it is easier to do every day than breaking that habit and introducing an exercise routine. The definition of being lazy, to me, is taking the easy way out, thus I personally find this behavior lazy.

Discrimination? Stereotyping? Bias? Yes, yes and yes. I would definitely prefer a healthy person to a non-healthy person in any business or social endeavor. (Unless it was a hot dog eating contest.) Yes, I stereotype obese people to be lazy, over-eaters, inactive and sedentary. I don't see anything wrong with this. I prefer to hold people accountable for their actions. If this upsets them, they can either lose weight or bear my bias. The only win-win is for them to lose weight.

Yes, google "obesity health care costs" and read the first 10 or so articles. PBS did a special on it as well.

I've been saying this for awhile, not because of fuel prices but because of comfort. It is rude for an overweight person to spill into adjacent seats.

Just like it is rude for overweight people to drive up the cost of health care because they refuse to take care of their own bodies.

It's a touchy subject, but I think we have a lot to gain as a society by telling people it's not OK to be lazy and fat, instead of silently judging them. (Save yourself the "Some people can't help it!" argument. No one is buying that the 33.8% of obese Americans fall into that category - it's a choice for them.)

It's not that this API is available to App Store only apps, it is that it is available only if you have a signing key from Apple. That is because these APIs make connections to Apple's server. It would make sense that Apple would, you know, not let just everyone into their server with every user's information.

So, this post is blatantly misleading, and whoever wrote it should be ashamed.

I don't think programming in its current form will become similar to unskilled labor. The important part about the examples at the beginning of the article (construction, factory workers) is that there were engineers (smart experts) behind the innovation that simplified a task so that an unskilled laborer could do it.

Can programming become so dumbed down that anyone could do it? Sure, there are plenty of tools out there that are "App Makers" for whatever platform/genre you want. But are those tools churning out apps that make a company? I haven't seen one.

The thing about software is that it is a ton of small pieces put together to create something new and unique. Factory workers put together a ton of small pieces, but to create something that has already been invented. A car, for example, has a specification created by smart people and put together by unskilled workers and machines.

The headline sounds interesting, but extremetech's mobile website is so awful I can't read it... Breaks the back button on iOS sometimes and what's with the forced pagination?

Eh. Not really seeing it.

I think the category approach is much better (cleaner, easier documented, conventional) and there really isn't a speed increase in using the preprocessor (anything that looks like a difference in time is due to either caching or CPU load at the time).

When it comes to games, OpenGL is still the best option. The animation system works well for moving around interface elements in two dimensions. The animation system does not work well for 3D or when you are modifying the bitmap content of a layer on the screen.

Will OSX ever catch up to Windows for games? Maybe. Some game companies take the approach of writing everything in OpenGL to make it easier to port between systems, writing a layer of native code to support their cross-platform code.

However, some studios use DirectX which is windows-only. The popularity of OSX and iOS will only increase the pressure on game developers (and engine developers) to write code that is easier to port.

Pretty close on the iOS stuff:

1. All* rendering takes place on the main thread in iOS.

2. The main thread doesn't always have the highest priority. In fact, its priority level changes throughout an application.

3. There is more than just one reason iOS rendering is so fast. Here are two important ones:

a. Animation is actually the basis of the entire rendering system. On desktop Cocoa, the drawing system was a little dated. The mistakes learned from this system and the desire to have fast animation led to the Core Animation framework and the idea of "layers". The ability to quickly composite layers (without moving any data from between the CPU and GPU) and only redraw when necessary is huge.

b. The batching together of drawing updates at the end of an event instead of on an as needed basis allows for huge performance gains.

* It is possible to draw in a background thread, but is reserved for particular situations (maps, web content, etc.). Table views do not fall into this category.

Not familiar with OAuth, but the concern about NSURLConnection seems a bit silly. Create an NSObject subclass, give it a NSURLConnection and a block ivar. Set it as the delegate of its own NSURLConnection. Setting up a "store" object that handles the preparation of NSURLConnection instances is also useful. Have the store keep track of all working NSURLConnections (which gives you the ability to cancel easily, too).

If you are using NSURLConnection out of the box and writing the delegate methods over and over again in every view controller or store object, you are doing something wrong.

Given that APIs, especially for iOS and Android, are evolving so quickly that your videos are already out of date, what is your plan for shooting new videos when content changes? Won't it be difficult to maintain the same professional editing and keep up with the changes for the given platform?

For example, the big players in iOS education (Big Nerd Ranch, Pragmatic) have been teaching iOS 5 since it was in beta; but you guys are on iOS 4.

The Middle East and the West all have "rules of law", here are some examples:

http://en.wikipedia.org/wiki/Sharia http://en.wikipedia.org/wiki/United_States_Constitution

Both were written some time ago. Both have been modified, "interpreted" or just plain ignored. People are people no matter where you go. Power ebbs and flows to different people and groups over time. You are currently born into the group with the most power. This does not make you more correct, better than, or more civilized than others. It just makes you lucky.

That's the whole point - "your" definition. There are billions of people in the world, any many of them disagree with your definition. Pretending your definition is the only definition is the height of egotism, and I wish that we as a people, could understand that and have sympathy and constructive conversations about the future.

You have that backwards, it should be: "I'm an isolationist, which is why I think the Middle East is uncivilized."

Also, politicians pandering to various religious communities happens all the time in America. Let's not pretend it is different because the people are brown and the word "God" is pronounced differently.

Shame on you.

Every Objective-C class/object is a C structure. Every Objective-C message send is actually a C function call (objc_msgSend). Every Objective-C method is actually a C function definition. So, to the contrary, every Cocoa project is just using C functions, types and using the ObjC runtime.

The point you are trying to make is that porting an ObjC application to another language would be difficult because of the syntax of the language, notably, the interspersing of arguments within the method name. My point is that this has zero relevance to adopting a new application-level API.

An application-level API hooks into OS-level calls (which are not ObjC), which gets turned into assembly, which gets turned into machine code. The only way Cocoa applications would no longer run is if the Cocoa library could no longer bridge the the operating system or if they intentionally did not ship the Cocoa library. Thus, creating a new application-level API would deprecate Cocoa, but wouldn't render those applications useless.

Clearly, a company would have to transition to the new language/API. However, once again, the syntax of ObjC would not make it any more difficult or easy to make this transition compared to any other language. And this did not stop Apple 10 years ago, so I don't envision this stopping them again (C Carbon -> ObjC Cocoa; note that you can still make Carbon calls on Mac OS X).