Learn one, then learn the other - start where you want to.
40 karma · joined January 12, 2009
Learn one, then learn the other - start where you want to.
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.
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.
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.
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.
Not had a single failure so far.
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:
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.
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.
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.
That is how I do it IRL.
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 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.
They will bite your hand off and you will be a rich man.
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.
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,