|
Ravi Bhavnani wrote: IMHO, that's because there are more Intel PCs sold than Macs, and not because Vista is more popular than OSX.
Not so fast buddy;
There are more x86-based machines with Vista sold than there are hardware-machines with OSX. Meaning that even Vista on a x86 apparently offers a better alternative. (Even compared with a free competing OS on the x86 hardware)
|
|
|
|
|
Is it possible to buy a generic x86 box and install OSX on it or will Apple only sell you the OS along with its hardware?
/ravi
|
|
|
|
|
Apple tries to make it so you can't install it on any machine (including VMs), but some people have managed to get around that.
|
|
|
|
|
That's what I thought. Which is why I don't think one can surmise that consumers prefer Vista to OSX. They're apples and oranges - or Apples and PCs.
/ravi
|
|
|
|
|
I don't think it is different for the majority of consumers though - most people buy their hardware and OS as a bundle, and it's not like you can buy a Mac with the option to have it running Windows either. Of course, you couldn't really include people who build their own machine in a fair comparison (like myself) because OSX isn't realistically an option for them.
|
|
|
|
|
As I replied below - you were expected to be psychic and realise that the part I was answering was the bit about IE 6 being the most popular browser.
|
|
|
|
|
Sure it was. When Vista came out, and everyone's hate for Vista made them like XP from a relative perspective.
|
|
|
|
|
I expected people to read my mind. My comment was that IE6 was never that popular.
|
|
|
|
|
I'm still wearing my tinfoil hat, unfortunately it stops the psychic waves in both directions...but in that case I agree with you completely.
|
|
|
|
|
Lately I have been working on building out my first non-trivial application with node. It has been a very interesting smashing of my brain cells. Coming from a strictly typed language and moving into a prototype based language has removed a lot of my tools from my tool belt. But of all the changes, I think it is the lack of IoC that is hurting me the most. Getting out of your comfort zone will also reveal your programming assumptions.
|
|
|
|
|
After reading the blog post, I still don't have an answer to "what the hell is he talking about?"
Terrence Dorsey wrote: Getting out of your comfort zone will also reveal your programming assumptions.
Metaphorically speaking, that is true of wetware too!
Marc
|
|
|
|
|
Some say that API design is one of the hardest things in programming. A few even go as far as to say you should have at least 10 years of experience to even attempt it. While I think this process can be sped up almost an order of magnitude by good mentorship, at one time or another we’ve all suffered under the API of an inexperienced programmer. Though, this does raise the question: what exactly is it about building libraries that can take up to 10 years to learn? Bad ideas usually seem like good ideas... until you have to use them.
|
|
|
|
|
Very good question. Now waiting for answer. 5!
Happy Programming
|
|
|
|
|
Terrence Dorsey wrote: what exactly is it about building libraries that can take up to 10 years to learn?
Well, speaking from experience, just because you have a set of functions that does what you want doesn't mean you have an API. You have to learn to think "how would someone else use this?" It's then that you begin to realize that your initial API isn't abstract enough, doesn't provide enough event notifications, doesn't provide ways for someone else to easily customize the behavior. Those 10 years are from using enough of someone else's API's to learn what not to do, and then figure out how to do it better yourself.
Marc
|
|
|
|
|
Building an API requires 2 main things>
1. Know exactly your goal
2. Give others the freedom to use it however they want to
In a way this seem like two conflicting defenitions but they aren't.
I don't know if you need 10 years of experience for that. You sure need a lot of experience using APIs and you'll have to crack your head building your first ones to be open minded enough for this.
Another pitfall developers usually fall into is confusing flexibility with complexity.
You don't need to be over complex to deliver flexible APIs.
Keep it simple. A good practice are the use overloads.
Have a good critical look at the .net Framework design... it's probably the most complex API I'll ever work with
I usually say that it's like a war game, you always have to be several moves ahead of your "enemy"
|
|
|
|
|
Sagas come out of the realization that particularly long-lived transactions (originally even just inside databases), but also far distributed transactions across location and/or trust boundaries can't eaily be handled using the classic ACID model with 2-Phase commit and holding locks for the duration of the work. Instead, a Saga splits work into individual transactions whose effects can be, somehow, reversed after work has been performed and commited. Tune in next week when you'll hear the thrilling conclusion to this pattern...
|
|
|
|
|
So, a saga is merely a repackaged commit-system? With the explicit explanation that you should use the "smallest" set of commands in a transaction possible?
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
Terrence Dorsey wrote: individual transactions whose effects can be, somehow, reversed after work has been performed and commited
aka : "undo"
|
|
|
|
|
I gave a talk at #DDD10 this Saturday about keeping JS sane. I had some questions after about the list of things I ran through so documented in all its glory are my current thoughts on development with a dynamic language like JavaScript. Javascript sucks and it doesn’t matter (that it sucks)
|
|
|
|
|
These operator keywords are a powerful tool, one that many of us don’t know about or we forget that they are available to us. Let’s try to make better use of these native language features, as they will help us improve our class design by keeping all of our object’s conversion concerns in one location. Until next time, may all your code compile, and all of your unit test pass!
|
|
|
|
|
More discussion of this post over here[^].
Director of Content Development, The Code Project
|
|
|
|
|
Let us now, step by step, our first sketch to use the shield using the Arduino IDE version 1.00. We will write a program that when it receives a call from a preset number (stored in a specific location on the SIM), rejects the call and sends an SMS in response to the caller with the value read from an input. That's right: turn your Arduino into a phone... with working example code.
|
|
|
|
|
Like everything they build, engineers at NASA's Jet Propulsion Laboratory (JPL) designed Curiosity's Sky Crane landing system to work. But nothing is guaranteed in spaceflight. The team wouldn't know for sure whether the mission's entry, descent, and landing (or EDL) was successful until they got confirmation from the rover. The problem was that Curiosity's landing site in Gale Crater would be out of range at touchdown, so the team brought in a communications relay: the Mars Odyssey orbiter. It was a simple and obvious solution, except that Odyssey experienced its first ever malfunctions weeks before Curiosity's landing.... You have to have been out on a long patrol to appreciate this properly.
|
|
|
|
|
Several weeks ago Steven Degutis posted the slides from his excellent presentation, The quest for the perfect programming language. In reading his slides I was reminded of a blog post made back in 2007 by Steve Yegge called The Next Big Language. With the benefit of hindsight that history provides, I would like to revisit the major points of Yegge’s Next Big Language, and address them in the context of Go. Is Go the next big thing? Probably not, but an interesting read nonetheless.
|
|
|
|
|
Node is popular with new programmers, and it’s popular because it makes concurrency easy. Yet strangely it isn’t a good fit for high concurrency applications because it isn’t robust. And how many new programmers are jumping straight into concurrency? What to make of that? In there lies, I believe, part of the secret of Node’s success. Node.js, aspirational marketing and you.
|
|
|
|