CookWithMe

Well, the target group of android police is existing android users. So they naturally compare it to phones they use.

The same was true with the iPhone 5: A lot of blogs that are mostly frequented by existing iOS users didn't bother to compare it to android phones, but just the iPhone 4S. E.g. these reviews were talking about the "huge" screen of the iPhone 5 and didn't compare to the dozens of android phones with bigger screens...

But I agree, either is weird.

Sorry, but it is not a game, it is a convention that afaik holds true for ALL languages that use exceptions. Using exceptions for control flow is widely accepted as a code smell.

There is a fundamental difference between throwing an exception and returning null. From http://en.wikipedia.org/wiki/Exception_handling: "Exception handling is the process of responding to the occurrence, during computation, of exceptions – anomalous or exceptional situations requiring special processing – often changing the normal flow of program execution." One should throw an exception when an anomalous situation appears, e.g. I can not connect to the database. Whereas returning null / returning an Option means that this case needs to be treated in the normal flow of execution, e.g. asking a Person-object for it's spouse. It is perfectly reasonable that a random person isn't married (so throwing an exception is wrong) but at the same time it should be impossible for the caller to ignore.

> It might be overlooked. But is it too much to assume that someone making a call will check the parameters and the return type?

http://news.ycombinator.com/item?id=4695587

Apparently it is too much to ask, even if the program is performing something super-important for security like SSL.

I'm just guessing here, but maybe he is not talking as much about the language itself but about the (default) VM? AFAIK, the VM of Ruby (but also Python and node.js) do not support parallel execution of threads (which is usually solved by starting multiple VMs and using an extra cache).

Compared to the VMs of Haskell, Erlang or the JVM one might call this primitive.

(I definitely wouldn't call it amazingly primitive and I am aware there is JRuby / Jython)

> isn't any different from checking from nulls everywhere

You would only check for nulls "everywhere" if all functions could potentially return null. Then, indeed, there is no difference. But (hopefully) not all functions will return null, so you'll probably have at most a single-digit percentage of functions that do.

The point is that by using Option, you are explicitly stating "This function can return null", making it impossible for the caller to ignore. If you write it somewhere into the docs, it is indeed easy to overlook.

This may not be as relevant when you are only working with your own code, but I find this (and static typing in general) most helpful when dealing with code from someone else, including the libraries one uses.

I think in most places you are earning enough to live comfortably. Far more important to overall happiness than $10k more or less is whether you enjoy your job, get along with the colleagues and have friends and a cool environment outside of your workplace.

The automatic grading has a huge advantage: It is nearly real-time, and improving the solution and re-submitting improves your score.

Having been a teaching assistant who corrected programming assignments (and also a student), I always wondered how many of the students would read my comments, would go back to their solution and actually improve it. Probably none. If I (as a student) received a comment about a solution I submitted two weeks ago, I often didn't instantly know what the corrector talked about. I had to go back to look at my code. I'm not sure I always did that when I was busy. Additionally, I think even if I acknowledged the comment, I wouldn't actually go ahead and fix my solution.

I'm taking the scala course right now, and when I submit a solution and something is flagged, my thoughts are right in the code, I still have all the files open in vim, sbt running... so I can instantly go and fix it. And there is a real incentive to do that, because my score will improve.

I found the style checker to be pretty good and helpful.

Because for some problems they give a hint, e.g. "this is solvable with a one-liner", the student could figure out himself whether he is on the right track or not.

Line-length could also be checked by implementing something similar to a style checker. It could also check if some methods that are supposed to be used (e.g. min/max) are being used.

I guess the author is correct in that automatic grading is not perfect and it's never going to be as good as talking with someone more experienced... but it can go pretty far. Having corrected programming assignments as a teacher assistant myself, I have to say that it can be a really tough job and an automatic grading system may give you more help. When I corrected an assignment, and there were a lot of issues with it, I would point out the most important ones. But an exhaustive list is really tough because there is time pressure. Also, I think it could be too demotivating for the student if he gets a list of 30+ issues from the corrector, I'd rather have him acknowledge the 3 most important ones.

Agreed. Release early and often is well known and accepted in software engineering... yet some stores do their best to make that impossible.

He publicly admitted that he cracks his ebooks. IANAL, but his missteps would be much easier to proof in court, compared to the case of the Norwegian kindle user.

But for some reason, I strongly doubt Amazon will ban him...

Good written article, I agree with most of it, except:

> Don’t just complain or critique, offer up solutions too;

I often had the feeling that, when I got offered a solution from a good guy who's opinion I value, the usually limited time could be better spend with critique or hints.

Say I describe my solution A and solution B is offered, I don't know why she/he values B more than A.

Could be: 1) She/he knows something about A or B that I don't. 2) I know something about A or B that she/he doesn't. 3) She/he doesn't have additional knowledge. but she/he weights it differently.

In cases 1) and 3) I can hardly go ahead and implement solution B correctly. Case 2) is actually not that unlikely if I have spent a lot of time on the topic.

So if instead she/he tells me what is wrong about A or which opportunity I may exploit, I can use that info to either do B, or more often, come up with C.

> it's how you continue to iterate and make beautiful, successful apps.

I think it's great that they officially support "release early and often"!

I'm technical, I build stuff myself, so take my opinion with a pinch of salt.

If you have built a non-technical throw-away prototype (paper, wireframe, ...), at some point you may find your testing is limited. IMO, a technical THROW-AWAY prototype is ok to be outsourced, because it'll take all the short cuts it can, and when you are done testing you want to change at least 50% of it anyway, so throwing away and starting from scratch is the right answer.

That said, I don't know if there are any agencies that do this. But you could probably find a freelancer that enjoys this type of work. You definitely need a tech co-founder when you build the real thing, though.

You are right, my wording was incorrect. I'll try to put what I wanted to say in the words of Dr. Thomas Puzak, IBM: "Everyone knows Amdahl's law, but quickly forgets it".

That said, Amdahl's law does NOT apply to problems, it applies to programs: https://en.wikipedia.org/wiki/Amdahl%27s_law What I was trying to say is that, from my experience, if you take an existing program and try to parallelize it with minimal effort (e.g. parallelize all loops), then you may end up with having a serious percentage of serial code. (Or you don't, because your data is large enough, see Gustafson's law: https://en.wikipedia.org/wiki/Gustafson%27s_Law ) However, if you put in more effort and re-architect the program, you'll usually worry about a lot of problems, but Amdahl's law is not one of them. Yes, you didn't "avoid" Amdahl's law (and you can find counter-examples where Amdahl's law is a real concern).

I actually heard a talk about ordering in in-memory databases. It basically comes down to Gustafson's law: If your dataset is rather small, the overhead of parallelization (some of which can be attributed to Amdahl's law) isn't worth it, you just do it on one core. But because your dataset is small, it is so fast that nobody cares. If your dataset is large, each core sorts a subset. Then you start aggregating, and the final aggregation is serial. However, because you already have sorted lists, you can use a different algorithm that merges this very quickly (but would perform bad on unsorted data). I can't remember any specific numbers, but the bottom line was that even with a very beefy server that had 4 sockets and plenty of cores, the serial part wasn't an issue in terms of overall performance. Keep in mind that the author talked about a Multi-core myth and not a Many-core myth.

Again, I don't argue that near-linear speedup is possible for most problems. Most often it's not. But naming Amdahl's law as the only reason is wrong.

Actually, newer server CPUs have that, in a way. Each core is technically identical, but the performance is not always identical and can be dynamically adjusted.

The most obvious example is dynamic overclocking, where one core (that ideally works on a sequential part) gets a higher frequency (the other cores are usually underclocked at the same time). Intel calls this Turbo Boost: http://en.wikipedia.org/wiki/Intel_Turbo_Boost

In Hyper-Threading enabled cores, you also have varying performance per core, i.e. if one core only hosts one active thread that is CPU-bound the execution is faster than if one HT-core hosts two CPU-bound threads.

So, it is technically feasible, but at the same time makes scheduling for the OS harder.

Edit: And it also makes app performance less predictable. And it's one of the reasons why you need to run serious benchmarks more than a couple of times.

Yes, there definitely are programs where this holds true (as I have said), but there are others where it does not. A simple, but perfectly reasonable example is brute-force search for cracking a password (if you got the hash of the password). Your dispatch is simple: send every node 1) the hash, 2) the number of nodes, 3) it's own number. With 2) and 3), each node can easily figure out where it starts. You need no more communication until one of the nodes finds the password.

See https://en.wikipedia.org/wiki/Embarrassingly_parallel

Again, you said "most parallel", and not "average parallel", and this is what I have commented on.

I know, I actually read the paper like a year ago. Actually, what was turned later into Amdahl's law is more or less a side-note in the paper :)

The parent said "most parallel programs", which I translated to embarrassingly parallel problems.

> But "real" supercomputers and clusters will spend the most money to reduce bottlenecks precisely because they want to run those programs that are the most limited by them.

I agree, but from the talks I have heard most time (= money) is spent trying to work around these bottlenecks as good as possible in software (i.e. incremental algorithms, pipelining, ...) to keep the machines busy. Then again, I hear a lot more talks about software than hardware, so you may be very right. If you have any particular example in mind, I would love to read about it!

The biggest myth is probably that the CPU is the most important part for performance. There are so many other bottlenecks that you can easily run into (drive, memory, memory bus, ...) that blindly updating the CPU (more MHz / more cores) is simply wrong.

"the most parallel programs" are those that run on supercomputers / huge clusters, and they don't have these bottlenecks...

But for the average parallel programs, you are (currently) right, I guess.

tl;dr Use the right tool for the job. You need to know your tool (CPU) and your job (application(s)).

I.e. an app which is heavily affected by Amdahls law doesn't really profit from more cores, where as highly parallel apps do profit a lot (see reference to Niagara architecture at the end).

What I find strange is that the article first introduces the difference between multitasking and multithreading in a rather lengthy manner, and then uses Amdahl's law, which only applies to multithreading. Especially, there is a gap on what is stated first: > "So multitasking means you are using multiple applications at the same time. Which you always do, these days." With the conclusion: > "With multi-core, your mileage may vary, depending on the algorithms used by the application (to what extent are they parallelized, and to what extent do they have to remain sequential?), and on the performance of the individual cores."

His discussion is all well when you have one app that is really needing the power and the other multitasking apps don't need much CPU (e.g. playing mp3 and such). Which is the case for most desktop systems, I'd say. For servers, it can be really different, and you could either have many processes running or one process is heavily optimized for multithreading and avoids Amdahl's law nicely. Then the discussion is kinda void.

"Not compatible with Linux" :(

Does anyone know whether this is planned for the near future?

Google Play: You can see country, language, carrier, device and android version of every install.

Another idea - have you heard of a concierge MVP? If you can pull it off, you can validate that your idea really solves a pain of the customer (right now you have probably validated that your customers have a pain).

I'll also recommend the book Running Lean by Ash Maurya, he gives very concrete instructions on what to do and it is a very guide with a lot of practical tips (vs. a high level description).

I don't know the exact definition of an idea being started on, so yeah... I'd say it's fine. If you had build a prototype, that would have definitely crossed the line. But you don't even have a landing page up, right?

I have only been to one (in Berlin) before, and there have been a couple of pitches where people did spend time previously researching. It's fine with me, if you are willing to leave some creative freedom and not force everything pixel-specific onto people.

Before you let it rest in your project folder, you can try to pitch your idea at a startup weekend or similar event (basically, hackers, designers and business people spend a weekend trying to "create" a startup, usually building a MVP and doing some customer validation).

If your pitch includes "I have a mailing list of X persons who are very interested in this and would love to spend money on it", then it is going to stand out. It is usually possible to build a really rough proof-of-concept in that time, and you can use that to validate your idea, to a certain extent. If you are lucky, you might even find some developers who find this project interesting enough to continue working on it after the weekend.

But you'll need some luck for this to work perfectly, so if you are super-serious about it, try the paths outlined by others here.

How about a meta-answer?

"I am really passionate about an interview question, which I like to call the most revealing job interview question.

It’s without a doubt my favorite interview question, because it only take 5 minutes and tells me a remarkable amount about candidates. Even though it’s not a technical question per se, I still give it to every programmer I interview.

[...]

For senior positions, I will ask a question early in the 5 minutes that is a complete tangent and has little to do with their goal. A star candidate will politely refuse to go down this rat hole and insist that we stay on topic. This seems unfair since an they’re in an interview and just doing what they’re being asked. In reality though, the very same thing happens often in real work. Even mangers do not innately know what is most important about a topic, and it’s key to have confident people on the team that add focus to conversations."

At a hackathon we developed an NFC app that can scan food packaging and give you the instructions and a kitchen timer: http://www.youtube.com/watch?v=sJ92FMl1qcE (I know, its blurry...)

After hacking with it, I have to say it is much more reliable than QR code scanning / barcode scanning. No problems with low light, shaking device etc. Replacing QR codes is probably not a very exciting use case, but I could see it happening.

I chuckled at this too. But a lot of iOS devs have been complaining that Android development is comparably hard because of the different screen sizes... well, there you go.

Why does the consumer gain anything? Windows Phone 8 will be released, no matter what the court says, and Nokia will release phones with it.

>> Following the Samsung verdict, Bill Cox, marketing director for Microsoft's Windows Phone Division tweeted: "Windows Phone is looking gooooood right now."

Is he saying that Windows Phone isn't looking good compared to Android if you ignore the legal troubles Android is in?