You wont go wrong with either. Javascript is good for in web pages verses python being the server side to produce dynamic pages. You'll find you probably use both in a web project anyway.
Learn one, then learn the other - start where you want to.
Right now no one knows when the release will be. What we have here is a limited beta release to 10,000 people or so, not the actual product launch. That will be coming at an unknown point in the future, probably. People are frustrated by this realisation because the makers claimed it would be the real release. But I think its been obvious for at least 2 months that it would exactly what it is today (no one expected the website to die of course but the product selling out in seconds they predicted correctly).
They deserve criticism for getting the launch wrong. Until the hardware gets tested we don't know if that works. My fear is that the hardware shows the same lack of attention and it doesn't work very well. It needs to be called what it is, a potentially great product with a disastrously bad launch.
Education might be the stated aim of the project but its not the limit of the device. This is a device similar to an Arduino except for the fact its got HDMI, USB, is about 700 times faster and in the order of 256 million times more RAM and its only 25% more expensive. Its a hardware hackers delight and a desktop capable computer. It is also a very real competitor for nettops which sell in the millions at a price point 5-10x higher than this.
It may very well be used by students to code, but that will be a niche it falls into right behind becoming the cheapest desktop capable computer ever built that isn't locked down. This could very well start a revolution in portable desktop computers that are really cheap. I personally think it is an exciting device but let down by the narrow vision of its application.
They ignored a lot of experienced advice given to them freely to get to this point. Its a shame really as this could have been a magically moment where they shifted a million devices in a week. Instead we are looking at 404 pages and there are no devices available if you do get through. A lot of potential customers have just been gone and will never return.
Or it could tarnish their reputation and kill the whole product. Lets hope the engineering of the actual product is a little better than the sales process. But I still think its kind of important not to give your potential customers a 404 as your first interaction or you run the very real risk of having zero conversions from all that homepage traffic.
The one thing you can say about incompetence is that its ignorant of its own condition.
This does not bode well to the quality of the product itself, the lack of basic skills and forethought is frightening. After all that "we know what we are doing" talk I guess we can now point and laugh.
One intel X25-M 80GB SSD. According to the SMART information 10% of its write life has been used over 1.5 years. Still going strong in a work machine used day to day.
Two OCZ Vertex 2E's 120GB (separate machines). Had both for 6 months and both are working reliably with no signs of problems or performance degradation.
Developers do a lot of 4KB operations. Source files tend to be small as do database updates.
The current market leader in this is the OCZ Vertex 3, a considerably faster drive than the Intel 510. Indeed intel's X25-M is better at 4KB operations than the new drive.
The 510 is a disappointment, get an OCZ Vertex instead, its cheaper and faster for the sorts of operations that matter. See anandtech for more details:
One of the reasons software gets released in scripts rather than packages is because the root package installation mechanism is root accessible only. Most companies restrict root access and package installation is blocked by proxies. The combination of which means that scripts that can be downloaded separately and run are much easier for enterprise developers to use and get started with.
Until the average enterprise realises that packaging and installation needs to be done better we will always have the need for mechanisms that hack around the problem that system admins cause for the users of the servers.
In industry you often get to set the estimates yourself. Missing the deadline has less severe consequences because its unlikely you'll get fired for missing the deadline by a day. But on your course its a fixed date and a big fat 0 awaits those who miss it.
Its worth mentioning that estimates are not plans to deliver. Make sure that as you give them in units that represent the amount of confidence you have. Industry recognises things aren't perfect and so often deadlines are a bit more fluid.
If someone else is setting your deadlines and estimating on your behalf its best to treat those with the contempt they deserve and provide your own estimate. Its a sad fact of our industry that this happens so frequently, but its best to nip it in the bud.
In general things are a lot more fluid in industry, the requirements need detailed understanding and the estimates are never right. The pressure is normally less severe, but it really depends on your boss and your dynamic with him/her. In a startup its self imposed pressure so you get to choose how severe it is and how hard you end up working.
Its important as a young developer to make sure you learn the things you are working with well. You need to avoid spending too much time at work so you can get in the necessary reading and practice that makes a better craftsman.
The modern IDE is chock full of features. So many that many less common edits are automated if you know the right keystrokes. It takes years to master all of the features and those features are constantly expanding month on month.
An IDE like Eclipse can take 1 GB of RAM to run on a decent sized project. Not only that but it will happily consume 4 CPUs as it verifies the code, and it'll only reach its full potential of resource usage on an SSD. But 1GB of RAM is less than £20, a quad core around £80 and a decent dev SSD for less than £200. Compared to the time cost of learning another tool this is absolutely nothing. Those tools in your IDE are there to save you time and a bit of hardware to be able to use those features quickly is worth every penny for the hours they save you.
Learning your IDE well matters, the resource constraints are easily fixed with minimal cash outlay. The difference between a MB and a GB for your editor is irrelevant when the difference is such a vast array of features and plugins which can save a lot of time.
Emacs and vim have a place in the world but an IDE is a vital part of a modern development set-up because of the productivity it brings. If you are going to develop software seriously make sure you buy hardware capable of doing it so you can use the best tools at hand.
Once you have good coverage of your code base you can make large changes, run the tests and be confident the system still works without actually starting it up and checking manually.
1) The first test I right is a functional end to end test that assumes the application is deployed and running with all configuration in place. That means there is a database and all the other parts necessary to run the application. The test follows BDD format (Given ... when ... then). Its purpose is to cross the bridge between high level functional requirement (I want X) to an executable spec for the aspects of that.
2) I then develop a series of unit tests. These don't require a database or even the file system, they are purely in the language of the application. I use a mocking framework to isolate to units and TDD out all the aspects.
3) Finally I write a performance test. A preloaded set of known data is inserted into an environment looks very similar to production. Any additional specialist data for the individual test is then loaded on top and the test is run and asserted against an expected maximum time.
The combination of the three is working OK for me but there are still gaps. Its hard to get the automated performance testing right as there are so many types of tests you actually want to run which are very hard to automatically verify.
I refactor at one of two times. Its either after I get my unit test working or its a change to the structure of some code so I can add a feature. So its an activity I am constantly doing throughout the day to make sure the new functionality is put in relatively well.
In the same way I can't count how long writing tests takes I can't count how long refactoring takes as its simply part of the normal development process. I only ever account for work that includes these activities because after doing it for so many years I realise you can't split them without doing a hack job.
The massive difference in random access speeds in comparison to sequential speeds is the thing that changed in the last 15 years. The gap between memory clock speed and CPU clock speed has been increasing for all this time, whereas prior to that they were often similar.
The impact is that random access has suffered and cache has become vital in coping with the majority of those seemingly random jumps. Algorithms like quicksort benefit from locality of reference and hence better utilise the cache than algorithms that theorectically do less work.
Its interesting to see it jump like this, but its not indicative of large programs so much as it is indicative of what happens when you randomly access memory and effectively nullify your cache and your memorys DDR properties. Thankfully most programs don't in practice do this, if they did the programs would run about as well as they did in the mid 90's on an original Pentium.
Ring Intel's CEO. You have the means to give him optimal layout for his CPUs saving them both massive amounts of time and more importantly space on CPUs. If you like you can also approach AMD and get the two bidding against each other.
They will bite your hand off and you will be a rich man.
As a real programmer I cringe at the Polymorphism example, only because I see the point of objects is to encapsulate data with the associated methods and this breaks all of that. Indeed you try to avoid inheritance and use composition instead because of the very problem exposed. These examples struck me as a deeply procedural low level way to represent these concepts, although that common simplicity does suggest that really all objects are is a way to do if statements better. That in itself is a idea that everyone knew but few people ever said.
I find the GUI editor with a mouse painful and this GUI isn't helping! With a heavily user optimised interface with at the very least some of the smarts of Excel and a lot of hot keys (get rid of the dialogs, stop making me right click to splice etc) then it has some potential.
What I think we need is this approach translated into a real language with real libraries that have side effects and all the lovely mess that is a real programming environment. Right now its hard to see just how bad it is for the other 99% of programming that is grabbing from a DB and throwing data on a screen (those poor corporate drones!).
How about the author hosts his website with the language! Building enough infrastructure to do that is bound to help advance the language to the point where its more than just a toy.
An interesting simple way to consider logic will be interesting to watch this evolve.
I installed lots of disks in Raid 5 into my spare machine, stuck it in a cupboard and use it as a file/backup and UPNP server.
All my other machines use the drives on their for storage and backup and use small and fast drives such as the WD Raptor instead of something like the Spinpoint 1TB drive.
Improves the performance of my real desktop and puts my data under linux rather than windows making remote access possible if I want to take the risk,
Learn one, then learn the other - start where you want to.