I recently wrote a blog post describing my implementation of Kruskal’s algorithm – a greedy algorithm using to find a minimum spanning tree (MST) of a graph – and while it does the job it’s not particularly quick.
You’ll hear about these myths most of the time on management level, but some of them can be found on the development level, too. IMHO it’s important to be aware of these myths to be prepared for possible discussions.
When asked:”What’s the best thing I can do right now to improve my code quality” I always answer: code reviews. A code review is the best bug preventer out there. And even more, I like its older brother better: Pair programming.
Scrum101 is a side project that I’ve been working on and off for over a year. It started as some experiments in video, because I wanted to learn how my live course material would translate into video and if there was something that I could do with that.
Stack Overflow stats on language popularity and the job market, Groovy reached 2.1, Apple did the right thing, and US immigration law could be improving. All of these stories plus 5 Tips to Optimize SSL, interactive Knockout.js tutorials, and 'the funnies'.
One of the challenges in a program is how you manage the checkins, especially if you have continuous integration. I am quite fond of continuous integration, no matter how large your program is. I also like short iterations. (Remember Short is Beautiful?)
In today's world of web architecture planning web application developer must face a lot of challenges in architectural planning, considerable amount of which are security issues. One of the most common security issues to date in web platforms is content and resource exposure. Accidental or not-so accidental data exposure is a problem known since begging of web itself.
When a team migrates to Agile methodology it becomes bit complicated. They get confused about the metrics to choose. This is because as such Agile methods are not prescriptive and freedom is given to the team to invent the ones which adds value to project.
Last time we got as far as rendering a cool-looking spaceship to the screen. We also talked a little bit about how we want to choose features: based on value. Now that we have a spaceship, it's time to figure out how to animate it.
This is what "software craftsmanship" gets us: an imposed segregation of those who "get it" from those who "don't" based on somebody's arbitrary criteria of what we should or shouldn't be doing. And if somebody doesn't use the "right" tools or code it in the "right" way, then bam! You clearly aren't a "craftsman".
Welcome back for episode 2! (Link to Part 1 included) It's time to implement our first real feature. And with that, comes a decision: what feature should we implement? Some map to fly around in? A way of keeping track of all the entities in the application? A game loop?