Not at all, given that he was an active member and prolific member of HN and now that he has taken a break from HN he has all this free time to just write.
I would refer to it as delusional perfectionism. You build up this image of what a great job you are going to do, but well you never end up doing it, until you encounter some outside pressure to just get it done. So that in the end you just get it done and it is most likely no where near perfection.
Although given that this seems to be run as an experiment, so far it seems to be rather successful. Granted, in the long term it might not be sustainable, but for the short term it can provide a number of benefits. First of all the designer will be getting lots of practice and making a number of contacts while building up a good portfolio of examples. Also the low price makes it a low risk for anyone trying it out, so it is the type of experiment they can be tried with little cost and quickly.
I would find it interesting to see what the designer ends up doing as a result of this experiment.
I have been experimenting with using the 30/30 technique posted earlier this week,and I have found to provides an interesting dynamic of carrot/stick. After having rested/played for 30 minutes, I feel guilty about not working so it helps to overcome procrastination. While working, I know I will have a break shortly, plus I want to make use of the time I have.
I have issues with procrastinating and staying focused on work, so I will often wait until the last minute to get something done, and use the pressure of the deadline to help motivate me and keep me working. This seems to help break that cycle.
Something like depends on the context of the whole application and how you want to organize it. The first way puts the emphasis on the /doctors/mjones/...
If you have other actions related to doctors like /doctors/mjones/contact, this way can provide a more coherent organization. Plus you can extend it to something like /labs/questdiagnostic/mri/slots?
So you can decouple the concept of 'slots' from doctor, allowing you to extend it to other types of appointments without having to alter slots. The parameters are the items that are also the most likely to vary. When making an appointment you will check multiple days, but you are much less likely to check multiple doctors. Plus the days are more temporal in nature while the list of doctors is going to stay the same for longer.
From my reading, this combined with the use of the unclean hands defense: http://en.wikipedia.org/wiki/Unclean_hands, helps to protect them against both types of damages.
As of now I am just using my own. The user can create an account with username/password. When they login, it will associate the user with the session object. Session management is handled by ring, although the session data resides in memory only. I have a function which wraps around the routes which require the user to be logged in and checks the session to make sure the user is not nil.
I am using hiccup for generating the html, compojure and ring for routing and request/response handling, jetty as the webserver and postgresql as the database
I have just finished the first iteration of a web app written in clojure and in the several hundred lines of code, I have a single variable which changes state.
Basically it add physicality to the virtual world. Part of the trend of the internet is to help connect people who are not physically present or close. So people can form groups with other people based on interest rather then on location. But there is still lots of value in connecting with people on a more physical level, and these types of services tap into that value.
I find that when ever I am working on something new or difficult, I feel stupid. The act of working on it reveals my ignorance and makes me confront the fact that I am not as smart as I think I am.
I don't think such an approach can work with Clojure since the concepts that you bring from other OO languages do not really apply. I originally tried learning on my own by just using the documentation that is there and what I already know. That did not work. I needed something like Programming Clojure to go over all of the basics because Clojure basics and C# basics are different. Without understanding the Clojure basics you cannot do much. Granted someone with more of a background in Lisp or other languages could get started quicker and jump right in.
You are going to see a pattern along the diagonal because every other number is even and never prime (excluding 2). So the only way for two primes to be touching is along a diagonal. Given that and our brains tendency to group items which are closer together as being related, anything along the diagonal will stand out more and appear to be a pattern. A more interesting picture would be one where all of the even numbers are omitted.
The difficult part is the burning the 2000 calories. You do not have complete control over how many calories you burn. In the example DrSprout gives, if your body senses that you are burning too many calories it may adjust what is it does to conserve energy. In this case by delaying the process of healing the muscles.
In short, the way to lose weight is by burning more calories then you consume. But the difficult part is finding out how to do so in a healthy and sustainable weight. The means for doing so will vary from individual to individual.
One risk is not being able to transfer luggage from one flight to the next, and if this happens then the airline loses money by having to fix the problem.
One of the biggest costs for an airline is fuel. By reducing uncertainty in load, this makes planning less risky and the company can make better decisions.
This reduces the cost of checked luggage, which they can then turn into a competitive advantage. Customers can check in their baggage without additional costs. Checked bagged is more efficient to load, hence the planes can be loaded and unloaded more efficiently, so more flights can be made.
What I also find useful is getting practices with bottom up approach. In math the way ideas are developed and presented are first with the low level definitions and axioms, and then from there using logic those ideas are combined to prove more complicated theorems which can be used to solve other problems more easily. Similar to how programs can be built starting off with the low level details and then building abstractions on top of those to make dealing with other problems more easily.
This skill in and of itself is useful regardless of the type of application one develops and how much actual math a problem needs.
Mostly it is a reaction to the over use of XML and how and why in many situations using something other then XML is beneficial. If a large swath of people of start using JSON without thinking about you will probably start seeing a similar reaction extolling the virtues of another format over JSON.
I think the problem that you are running into is that while the concept is simple and essentially what they have done is make it simple to upload/download files and easily share across computers with yourself and others, this is a nontrivial problem. On top of that, the implementation works seamlessly across different operating systems. The reaction you are running into is probably akin to people who love the iPod. A device which does one thing and does it well.
As you have seen others mention, by creating a solution to a nontrivial problem (and if you have ever had to deal with file synchronization you know this is not simple) it has enabled usage scenarios that were previously too difficult to accomplish or at least not worth the hassle. So I can understand people's reactions to your comments.
But it only cost $1500 extra. His salary is already in the budget. No need to do a fund raiser to pay him. At which point, since that money was going to be spent anyways, the only real cost from his time is the opportunity cost for what else he could have been doing.
To me, the interesting part was the fact that the App store was basically an after thought. Given how popular it has become indicates that it is filling a need. The long term viability of it is in question, but I think it has a good chance of sticking around.
Then again that is true regardless of what martial art you practice. Without people who are capable of giving solid, well intentioned strikes you will learn little of any practical use. Although the likelihood of finding such people probably does vary by art, and having studied some Aikido besides the teacher and some of the more advanced students, most did not know how to (including myself).
When using math for real world applications, you essentially have three steps. First translate the problem into a math problem. Then manipulate the math problem as needed, then finally convert back the real world problem. But in most classes, the second step is the only part that is covered. This is the part where most people have problems, since people are wired to deal with the world around them, not some abstract math world. Trying to ground the math concepts to real world situation is difficult and complicated, which is probably why this step is skipped.
They are, hence the Unladen Swallow project. But the improvements are that are possible are constrained by the language and having to maintain backwards compatibility. If Google were to just take the language and do with it what they want, they would risk alienating the community which would weaken the utility of the language. So while improvements are being made, the types of improvements are limited.