When the world moves to OLED displays, the holes will increase the number of white pixels, which will increase energy consumption! That's assuming most programs show text on a black background... The contribution to greenhouse gases will be enormous. This font alone will cause the destruction of New York, Deep Impact-style. Mark my words.
I think the iPhone has one major achilles' heel which is Apple's ludicrous approval process. Developer frustration is beginning to boil over as many go weeks and months without so much as a peep as to where their hard work stands. And then after waiting for so long, they get notified that there's a misspelling, or that Apple doesn't like your icon.
If they continue to alienate developers like this, and if Google, RIM, Nokia, and Microsoft provide a far more open experience, I think you'll start to see this juggernaut start to slow down. Other factors include just how much stupid stuff an AppStore user has to wade through to get to the good apps, and the extreme fragility of the Xcode code signing / deployment system is (sudden 0xE8000001 errors with the SDK 2.2 update, anyone?)
iPhone is a good platform to develop for, but Apple's inability to get its SDK tools solid and its completely confusing, inconsistent, and nebulous approval system are just plain painful.
With an older, more experienced team, I would stay focused on constantly thinking and discussing things in the context of what's good for the team. Never make it about right and wrong, but always frame it in the context of moving forward. When two team members conflict in their technical views, they can either choose to take it personally or not. If you hear them both out and give them both a sense that their views were well considered, then the loser (for lack of a better term) can choose to either respect your decision or not.
The only tricky part comes when a team member chooses to start sabotaging your role. This often takes form of saying nasty things about you during lunches you're not invited to, and constant disagreement with anything you say. In that case, you're actually dealing with a very inexperienced developer pretending to be experienced. At that point, you've got to go through the 3-step: warn, document, then fire.
I think there isn't a real need to migrate from a 2D to a 3D paradigm because the paradigm is actually already as 3D as it will get before we need a different type of display altogether. I think that the real value of a 3D desktop is incrementally improved window management and eye candy (which is not to say they aren't important).
Still, I see 3D vs 2D more of an underlying tech thing instead of a user thing. I see it more like the switch from programmers using indexed paletted bitmaps to full RGBA bitmaps, or use of the GPU as a computing unit versus just the CPU. Nothing fundamental changes for the user, but the improvements are indeed palpable.
What makes a UI 3D in the first place? Is CoverFlow 3D? Why is it better than my thumbnail list views? It's certainly pretty to look at.
I'm days away from releasing my game on AppStore, and all the while during development, I watched prices plummet. Very disheartening and demotivating. This happens initially with any open market system, and the thing that needs to fundamentally change is not the system, but expectations.
Too many iPhone developers go into this thinking they'll be the next Trism and Ocarina. That's fine, but you'll probably also dive deep into disappointment, which turns to anger, and then to finger pointing. Get your expectations straight, and you'll do yourself less emotional damage.
Something developers are also missing is how many people out there actually have the right expectations. A lot of devs do their apps because it's cool and they are fascinated with making software, beyond the money aspect. That's where the $.99 toys come from. They are the stones that devs with dollar signs in their eyes are cast upon.
Forget trying to make your living on AppStore alone. You'll always hear about the few who made it huge, and the rest of us who are satisfied that we made something cool and where the income is all extra. It sucks, but if you want a higher chance of making it rich, either join a startup with stock options, or be the best.
In other words, from here on in, you'll only make your living on AppStore if you are absolutely phenomenal, or phenomenally lucky. Otherwise, be in it for the fun of it.
I've had many different instructors and professors who all taught a bit differently. I remember my CS class, where the TA (likely just following the prof's program) gave us a "middleware" OS, and we essentially had to provide the guts to execute different pre-written programs. That sucked. I left not understanding OS's. Another professor threw compiler theory (the dragon book) at us, and asked us to write a Pascal compiler.
I didn't get it (probably because I'm stupider than your average CS student).
What would have helped (in the case of the compilers class) is to have us newbies who just learned C write some simple parsers. Then, have us write some basic assembly programs (or MIX, or some byte code). Then, write a more complicated parser - aha! so THAT's why lex/yacc is cool. Then, have us write some assembly, and then more complicated assembly programs. Then, generate assembly from a simple language - aha! that's why we push stuff on a stack, that's why we have return addresses, etc...
I think the most effective teachers will understand how their slower newbie students think instead of that grad student trying to fill in some lost undergrad credits.
That said, another good way teach is to challenge students and provide the materials and support to let them succeed. My graphics professor gave us a picture of psychidelic mirrored spheres and told us, "write a program that generates this." Man, I had no idea, but I sure wanted to do it, and I did the research, and I didn't fail.
Much better than, "here's paragraphs of arcane terms and strange symbols - figure it out or drop out."
That's the carrot. The stick, of course, is that development on Microsoft's platforms is no longer interesting. Desktop is dead, both on Windows and Mac, so WPF, Cocoa, etc - those are boring. I don't care about database applications with cool graphics. I don't care about awesome list view widgets, XML UI, etc. Those are just nuts and bolts which are pointless unless there's something compelling to build. The potential of iPhone is compelling.
That said, and this is totally biased from this Windows dev, to me Xcode doesn't compare to Visual Studio. I find VS's debugging, editing, and pretty much everything else to be slicker and more stable (at least, in VS2008sp1). I find getting a quick-and-dirty Windows app to be faster to slap together than an equivalent Cocoa app (eg. creating a quick game level editor). I also prefer the single-window IDE, and VS.NET works better in that layout. The IDE morphs to be a good debugger IDE when debugging. I find STL debugging easier, as well. MSDN documentation is a library of congress compared to Xcode's docs. But again, a more experienced Xcode dev will kick my ass on these points.
Little extras: I love having a real command line. I love not having installers be its own entire dev cycle.
What would be really neat is having actors wear normal clothes when shooting a scene, and letting the costume staff layer them on in post production.
But what would really be cool is some technology to remove the digital creatures from Star Wars. Oh wait.
Isn't SpaceX close to launching astronauts into space with their Falcon 9 and Dragon? This sounds like a big opportunity for private space industry to fill this need.
Wake me up when they support iPhone and WinMo. For that matter, wake me up when they have *Flash* for iPhone:-)
Also, I propose a Silverlight interpreter written in Flash. I think they should call it Flashlight.
You're right - I haven't used the Eee, but I've used the Acer Aspire and found it to be perfectly good. No CE.
You know, I have no specific desire to press a button named "Start" to launch a program. I have no specific need for the "X" button to be in the upper right.
Let's see - instead of using an OS that has tons of great software for it, has no licensing fees, and is quickly source-modifiable by the manufacturer, we can instead use an OS that has lots of crappy software for it, costs money, and takes several quarters for the maker to fix bugs.
Hmmm, tough one...
Also, what part of the "Windows experience" in WinCE is that valuable? Win32 apps don't work on it, so that's out. Can anyone name a good office suite for WinCE? What, is the Start button that awesome? Are WinCE clickable icons so much better than those under Linux UI's? Cmon.
Really, as a long time Windows dev and an avid WinMo developer, I just don't see the value for netbook makers.
Whatever happened to: Work hard, be smart, learn, and respect others?
I tend to think these things are 90% of being successful, and the other 10% are the kinds of tactics the author lays out. I haven't seen people pull their former coworkers into a company because they decided to learn XYZ. Chances are, XYZ programmers are not in short supply. It's the other qualities that make one a pleasure to work with productively that trumps everything else.
First question is: who is the logging for?
Sometimes the logging is for the customer, sometimes it is for support, often it's for the developers, and often it's for some combination of these.
If it's for the customers, the readability, volume, and performance are all considerations. But if it's for the devs, requirements can vary greatly. Some people here say, "what about CPU" and others say "what about disk space?"
If I'm logging for an app on a 5 petabyte system that only runs a relatively small chunk of code once per day, I'll go ahead and log every line if that helps in some way. If I'm logging for an embedded app with about 32k of free space, I'm going to log very differently.
Logging should be fit to your needs - anyone who tells you that your logging is wrong is probably wrong.
For example, I took a lot of flak in my company for having *extremely* verbose logs. Our support, who like to look at logs, blamed me for making the logs way too huge. I then got the linux server guys lecturing me about the proper way to log - I apparently should only log critical errors, and I should have several different log levels, right?
WRONG. The product in question is a plugin, and relies on very flaky API's. It is subject to interference from other plugins and bugs in the host application itself. Having several log levels only lead to too much back-and-forth between support and customer (ok, now try THIS log level. ok, now try THIS log level. ok try...).
So, for my needs, where anything can go wrong at any time, super verbose, scope-indented logs were absolutely necessary.
For other needs, only critical errors need be logged. And every need in between has justification as well.
There is absolutely no rule, and as long as your logging meets your needs, no one has any business telling you how to do what they don't understand.
If nothing actually exists unless it is observed, that implies that the observer has some indeterminate property that is affected by the observation. Otherwise, it would not be an observation. Either everything we see is created like a instant virtual reality for us (which I doubt) or everything in the universe is at some level able to observe and react. Seems to me that animals are simply an incredibly efficient machine for coordinating these observations and producing a coordinated reaction.
In other words, I think the universe can't exist unless there is free will.
I wonder how much control future ray tracing engines will give the programmer over scene search algorithms? If I'm doing a top-down terrain render, I'd want to have a super-simple O(C) first hit time (probably using a simple grid/bucket). If I were doing a space scene, maybe an oct tree. In either case, it sounds like a problem that can't easily be hardware accelerated.
I'm admittedly only very journeyman in my understanding of RT (I've written some basic RT's). How would they slow down? You can process bump maps pretty easily - it's still just adjusting the diffuse light value based on a tweaked surface normal.
I think raytracing is going to be the only way to go in 5-10 years. As poly counts go up, average poly size is going to drop below 1 pixel, and the overhead of tracing rays will match the overhead of rasterizing tiny polys + scene overdraw, etc.
Of course, what I fear is that all the games will start feature too much reflection on every surface, because they can.
Slashdot Mirror
When the world moves to OLED displays, the holes will increase the number of white pixels, which will increase energy consumption! That's assuming most programs show text on a black background... The contribution to greenhouse gases will be enormous. This font alone will cause the destruction of New York, Deep Impact-style. Mark my words.
I think the iPhone has one major achilles' heel which is Apple's ludicrous approval process. Developer frustration is beginning to boil over as many go weeks and months without so much as a peep as to where their hard work stands. And then after waiting for so long, they get notified that there's a misspelling, or that Apple doesn't like your icon. If they continue to alienate developers like this, and if Google, RIM, Nokia, and Microsoft provide a far more open experience, I think you'll start to see this juggernaut start to slow down. Other factors include just how much stupid stuff an AppStore user has to wade through to get to the good apps, and the extreme fragility of the Xcode code signing / deployment system is (sudden 0xE8000001 errors with the SDK 2.2 update, anyone?) iPhone is a good platform to develop for, but Apple's inability to get its SDK tools solid and its completely confusing, inconsistent, and nebulous approval system are just plain painful.
With an older, more experienced team, I would stay focused on constantly thinking and discussing things in the context of what's good for the team. Never make it about right and wrong, but always frame it in the context of moving forward. When two team members conflict in their technical views, they can either choose to take it personally or not. If you hear them both out and give them both a sense that their views were well considered, then the loser (for lack of a better term) can choose to either respect your decision or not. The only tricky part comes when a team member chooses to start sabotaging your role. This often takes form of saying nasty things about you during lunches you're not invited to, and constant disagreement with anything you say. In that case, you're actually dealing with a very inexperienced developer pretending to be experienced. At that point, you've got to go through the 3-step: warn, document, then fire.
I think there isn't a real need to migrate from a 2D to a 3D paradigm because the paradigm is actually already as 3D as it will get before we need a different type of display altogether. I think that the real value of a 3D desktop is incrementally improved window management and eye candy (which is not to say they aren't important). Still, I see 3D vs 2D more of an underlying tech thing instead of a user thing. I see it more like the switch from programmers using indexed paletted bitmaps to full RGBA bitmaps, or use of the GPU as a computing unit versus just the CPU. Nothing fundamental changes for the user, but the improvements are indeed palpable. What makes a UI 3D in the first place? Is CoverFlow 3D? Why is it better than my thumbnail list views? It's certainly pretty to look at.
I'm days away from releasing my game on AppStore, and all the while during development, I watched prices plummet. Very disheartening and demotivating. This happens initially with any open market system, and the thing that needs to fundamentally change is not the system, but expectations. Too many iPhone developers go into this thinking they'll be the next Trism and Ocarina. That's fine, but you'll probably also dive deep into disappointment, which turns to anger, and then to finger pointing. Get your expectations straight, and you'll do yourself less emotional damage. Something developers are also missing is how many people out there actually have the right expectations. A lot of devs do their apps because it's cool and they are fascinated with making software, beyond the money aspect. That's where the $.99 toys come from. They are the stones that devs with dollar signs in their eyes are cast upon. Forget trying to make your living on AppStore alone. You'll always hear about the few who made it huge, and the rest of us who are satisfied that we made something cool and where the income is all extra. It sucks, but if you want a higher chance of making it rich, either join a startup with stock options, or be the best. In other words, from here on in, you'll only make your living on AppStore if you are absolutely phenomenal, or phenomenally lucky. Otherwise, be in it for the fun of it.
Once Apple builds this into the next iPhone, everyone will be able to see what a perv I am.
I've had many different instructors and professors who all taught a bit differently. I remember my CS class, where the TA (likely just following the prof's program) gave us a "middleware" OS, and we essentially had to provide the guts to execute different pre-written programs. That sucked. I left not understanding OS's. Another professor threw compiler theory (the dragon book) at us, and asked us to write a Pascal compiler. I didn't get it (probably because I'm stupider than your average CS student). What would have helped (in the case of the compilers class) is to have us newbies who just learned C write some simple parsers. Then, have us write some basic assembly programs (or MIX, or some byte code). Then, write a more complicated parser - aha! so THAT's why lex/yacc is cool. Then, have us write some assembly, and then more complicated assembly programs. Then, generate assembly from a simple language - aha! that's why we push stuff on a stack, that's why we have return addresses, etc... I think the most effective teachers will understand how their slower newbie students think instead of that grad student trying to fill in some lost undergrad credits. That said, another good way teach is to challenge students and provide the materials and support to let them succeed. My graphics professor gave us a picture of psychidelic mirrored spheres and told us, "write a program that generates this." Man, I had no idea, but I sure wanted to do it, and I did the research, and I didn't fail. Much better than, "here's paragraphs of arcane terms and strange symbols - figure it out or drop out."
If you can't see it, but it's there . . . it's a bug.
iPhone
That's the carrot. The stick, of course, is that development on Microsoft's platforms is no longer interesting. Desktop is dead, both on Windows and Mac, so WPF, Cocoa, etc - those are boring. I don't care about database applications with cool graphics. I don't care about awesome list view widgets, XML UI, etc. Those are just nuts and bolts which are pointless unless there's something compelling to build. The potential of iPhone is compelling.
That said, and this is totally biased from this Windows dev, to me Xcode doesn't compare to Visual Studio. I find VS's debugging, editing, and pretty much everything else to be slicker and more stable (at least, in VS2008sp1). I find getting a quick-and-dirty Windows app to be faster to slap together than an equivalent Cocoa app (eg. creating a quick game level editor). I also prefer the single-window IDE, and VS.NET works better in that layout. The IDE morphs to be a good debugger IDE when debugging. I find STL debugging easier, as well. MSDN documentation is a library of congress compared to Xcode's docs. But again, a more experienced Xcode dev will kick my ass on these points.
Little extras: I love having a real command line. I love not having installers be its own entire dev cycle.
What would be really neat is having actors wear normal clothes when shooting a scene, and letting the costume staff layer them on in post production. But what would really be cool is some technology to remove the digital creatures from Star Wars. Oh wait.
Isn't SpaceX close to launching astronauts into space with their Falcon 9 and Dragon? This sounds like a big opportunity for private space industry to fill this need.
Nothing that dares to stand the test of time ever wins. As soon as you add a zero or three to the requirements, any tech becomes badly built.
Wake me up when they support iPhone and WinMo. For that matter, wake me up when they have *Flash* for iPhone :-)
Also, I propose a Silverlight interpreter written in Flash. I think they should call it Flashlight.
Nah, I think the future is a big ol' gob of Win32.
You're right - I haven't used the Eee, but I've used the Acer Aspire and found it to be perfectly good. No CE. You know, I have no specific desire to press a button named "Start" to launch a program. I have no specific need for the "X" button to be in the upper right.
Let's see - instead of using an OS that has tons of great software for it, has no licensing fees, and is quickly source-modifiable by the manufacturer, we can instead use an OS that has lots of crappy software for it, costs money, and takes several quarters for the maker to fix bugs. Hmmm, tough one... Also, what part of the "Windows experience" in WinCE is that valuable? Win32 apps don't work on it, so that's out. Can anyone name a good office suite for WinCE? What, is the Start button that awesome? Are WinCE clickable icons so much better than those under Linux UI's? Cmon. Really, as a long time Windows dev and an avid WinMo developer, I just don't see the value for netbook makers.
Oh wait, never mind.
Whatever happened to: Work hard, be smart, learn, and respect others? I tend to think these things are 90% of being successful, and the other 10% are the kinds of tactics the author lays out. I haven't seen people pull their former coworkers into a company because they decided to learn XYZ. Chances are, XYZ programmers are not in short supply. It's the other qualities that make one a pleasure to work with productively that trumps everything else.
First question is: who is the logging for? Sometimes the logging is for the customer, sometimes it is for support, often it's for the developers, and often it's for some combination of these. If it's for the customers, the readability, volume, and performance are all considerations. But if it's for the devs, requirements can vary greatly. Some people here say, "what about CPU" and others say "what about disk space?" If I'm logging for an app on a 5 petabyte system that only runs a relatively small chunk of code once per day, I'll go ahead and log every line if that helps in some way. If I'm logging for an embedded app with about 32k of free space, I'm going to log very differently.
Logging should be fit to your needs - anyone who tells you that your logging is wrong is probably wrong. For example, I took a lot of flak in my company for having *extremely* verbose logs. Our support, who like to look at logs, blamed me for making the logs way too huge. I then got the linux server guys lecturing me about the proper way to log - I apparently should only log critical errors, and I should have several different log levels, right? WRONG. The product in question is a plugin, and relies on very flaky API's. It is subject to interference from other plugins and bugs in the host application itself. Having several log levels only lead to too much back-and-forth between support and customer (ok, now try THIS log level. ok, now try THIS log level. ok try...). So, for my needs, where anything can go wrong at any time, super verbose, scope-indented logs were absolutely necessary. For other needs, only critical errors need be logged. And every need in between has justification as well. There is absolutely no rule, and as long as your logging meets your needs, no one has any business telling you how to do what they don't understand.
Sorry, my subatomic overlords commanded me to post that.
If nothing actually exists unless it is observed, that implies that the observer has some indeterminate property that is affected by the observation. Otherwise, it would not be an observation. Either everything we see is created like a instant virtual reality for us (which I doubt) or everything in the universe is at some level able to observe and react. Seems to me that animals are simply an incredibly efficient machine for coordinating these observations and producing a coordinated reaction. In other words, I think the universe can't exist unless there is free will.
I wonder how much control future ray tracing engines will give the programmer over scene search algorithms? If I'm doing a top-down terrain render, I'd want to have a super-simple O(C) first hit time (probably using a simple grid/bucket). If I were doing a space scene, maybe an oct tree. In either case, it sounds like a problem that can't easily be hardware accelerated.
I'm admittedly only very journeyman in my understanding of RT (I've written some basic RT's). How would they slow down? You can process bump maps pretty easily - it's still just adjusting the diffuse light value based on a tweaked surface normal.
I think raytracing is going to be the only way to go in 5-10 years. As poly counts go up, average poly size is going to drop below 1 pixel, and the overhead of tracing rays will match the overhead of rasterizing tiny polys + scene overdraw, etc. Of course, what I fear is that all the games will start feature too much reflection on every surface, because they can.