SE News

Project Euler is a series of challenging mathematical/computer programming problems that will require more than just mathematical insights to solve. Although mathematics will help you arrive at elegant and efficient methods, the use of a computer and programming skills will be required to solve most problems.
The motivation for starting Project Euler, and its continuation, is to provide a platform for the inquiring mind to delve into unfamiliar areas and learn new concepts in a fun and recreational context.

http://projecteuler.net/

Deadlock immunity is a property by which programs, once afflicted by a deadlock pattern, develop the ability to avoid future occurrences of that deadlock pattern. Over time, programs with such an “immune system” progressively increase their resistance to deadlocks.

Dimmunix is a tool for giving software systems such an immune system against deadlock, without any assistance from programmers or users. Dimmunix is well suited for general purpose software (desktop and enterprise applications, server software, etc.) and a recent extension allows application communities to collaborate in achieving enhanced immunity.

http://dslab.epfl.ch/proj/dimmunix

This article presents some common behaviors I’ve observed from my past few years of interactions with geeks, nerds, and other highly-smart technical people. For brevity, I will simply use the term “geek” throughout this article as a catch-all term for such people. I don’t mean to pass any value judgments on people who exhibit such behaviors; these are simply my observations and personal theories for why these behaviors occur.

Philip Guo

http://www.stanford.edu/~pgbovine/geek-behaviors.htm

This installment of Evolutionary architecture and emergent design tackles a variety of topics related to evolutionary architecture, including the important distinction between design and architecture (and how to tell them apart), some issues that come up when you create enterprise-level architecture, and the difference between static and dynamic typing in service-oriented architectures. This installment rectifies the lack of material about agile architecture.

Neal Ford

http://www.ibm.com/developerworks/java/library/j-eaed10

Until the 1980s, using a computer program meant memorizing a lot of commands and typing them in a line at a time, only to get lines of text back. The graphical user interface, or GUI, changed that. By representing programs, program functions, and data as two-dimensional images — like icons, buttons and windows — the GUI made intuitive and spatial what had been memory intensive and laborious.

But while the GUI made things easier for computer users, it didn’t make them any easier for computer programmers. Underlying GUI components is a lot of computer code, and usually, building or customizing a program, or getting different programs to work together, still means manipulating that code. Researchers in MIT’s Computer Science and Artificial Intelligence Lab hope to change that, with a system that allows people to write programs using screen shots of GUIs. Ultimately, the system could allow casual computer users to create their own programs without having to master a programming language.

http://sikuli.csail.mit.edu/

Éric Lévénez has compiled a computer languages timelime, listing the history of 50 programming languages in a chart.

Éric Lévénez

http://www.levenez.com/lang/

The rate at which power-management features have evolved is nothing short of amazing. Today almost every size and class of computer system, from the smallest sensors and handheld devices to the “big iron” servers in data centers, offers a myriad of features for reducing, metering, and capping power consumption. Without these features, fan noise would dominate the office ambience, and untethered laptops would remain usable for only a few short hours (and then only if one could handle the heat), while data-center power and cooling costs and capacity would become unmanageable.

As much as we might think of power-management features as being synonymous with hardware, software’s role in the efficiency of the overall system has become undeniable. Although the notion of “software power efficiency” may seem justifiably strange (as software doesn’t directly consume power), the salient part is really the way in which software interacts with power-consuming system resources, [and how it can] contribute to (or undermine) overall system efficiency.

Eric Saxe

http://queue.acm.org/detail.cfm?id=1698225

The W3C (World Wide Web Consortium) has posted a draft set of APIs that Web applications could one day use to store structured content offline. The proposed standard, recently renamed as the Indexed Database API, will provide an interface that Web application developers could use to have a user’s browser store database content for offline use […].

Typically, today’s Web application, such as a browser-based e-mail client or a calendar, will draw its user data from a database that is accessible from a network. In some cases, however, the user may wish to use the application while not connected to the network. Web applications could use these APIs (application programming interfaces) to store copies of the data in the browser itself.

http://www.w3.org/TR/2010/WD-IndexedDB-20100105/

Scrum and Kanban are two flavours of Agile software development - two deceptively simple but surprisingly powerful approaches to software development. So how do they relate to each other? The purpose of this book is to clear up the fog, so you can figure out how Kanban and Scrum might be useful in your environment.

Part I illustrates the similarities and differences between Kanban and Scrum, comparing for understanding, not for judgement. There is no such thing as a good or bad tool – just good or bad decisions about when and how to use which tool. Part II is a case study illustrating how a Scrum-based development organization implemented Kanban in their operations and support teams.

Consistent with the style of “Scrum and XP from the Trenches”, this book strikes a conversational tone and is bursting with practical examples and pictures.

Henrik Kniberg and Mattias Skarin

http://www.infoq.com/minibooks/kanban-scrum-minibook

Codility is an automated test of programming skills necessary in recruitment of software developers. It enables recruiters without specialized IT knowledge, to quickly run automated assessment tests for programming skills. It’s aim is to verify how well the candidate will perform in a day to day job. To test employee with exactly the same tasks he needs to deliver.

With Codility you get:
* Reduced cost of recruitment by up to 90%
* Increased quality of hires
* Statistics comparing your candidates vs market averages

With Codility you can:
* implement first line of candidate screening
* substitute at least one technical interview
* setup tests in 7 programming languages
* set 3 levels of difficulty of programming tests

http://codility.com/

Dive Into HTML5 seeks to elaborate on a hand-picked selection of features from the HTML5 specification and other fine standards. I shall publish drafts periodically, as time permits. The final manuscript will be published on paper by O’Reilly, under the Google Press imprint. Pre-order the printed work and be the first in your community to receive it. The work shall remain online under the CC-BY-3.0 license.

Mark Pilgrim

http://diveintohtml5.org/

Cloud computing allows companies to store and process data more efficiently than ever. But the code that’s used to control the machines in a computing “cloud” remains surprisingly clunky. Now some researchers are exploring novel programming languages for controlling the cloud, and they’re borrowing an approach developed in the ’80s.

Most programming languages were never designed handle so many computers or so much data spread out across them. Software frameworks such as Google’s MapReduce and an open competitor called Hadoop provide handy tools for doing this. But there’s room to make the process much more efficient.

Erica Naone

http://www.technologyreview.com/computing/24220/

I had to work late and my manager supported by staying late with me. If he was somewhat technical, he could have asked relevant questions or maybe even offered helpful suggestions. But he hadn’t written code in years – and never in the language I was using. He just slowed me down.

I’m now a manager for a team of developers. It’s getting late one afternoon and a customer calls me up and starts yelling in my ear. Some system we sold them was down and they had to produce reports by the following morning or there would be hell to pay.

Of course I stayed late with my developer to solve this customers’ problem. And guess what? Yep, I hadn’t coded in years and never in the language he had to work with. So I could offer very little in the way of technical guidance.

When a manager tells his developers to work late, should he stay late too?

Eric Spiegel

http://itmanagement.earthweb.com/article.php/3854421/When-Developers-Work-Late-Should-Manager-Stay-or-Go.htm

Ward Cunningham coined the metaphor of technical debt in 1992. “Shipping first-time code is like going into debt,” he said. “A little debt speeds development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid.”

For large software projects, using debt is often a wise financial strategy. But incurring debt is always a risk, especially if it is high-interest debt and you’re not paying close attention to the cost. The same is true of technical debt, and it applies not only to code but also to architectural design and even to requirements analysis.

What is your project’s analysis debt load? What’s the difference between good and bad analysis debt? What are causes and remedies for such debt? Mary Gorman and Ellen Gottesdiener explore the concept of analysis debt and consider strategies for prudent investing.

Mary Gorman/Ellen Gottesdiener

http://www.stickyminds.com/s.asp?F=S15549_ART_2

At the end of the day, it’s not whether you’re following one process or another that matters, but whether your approach successfully delivers software that people like using—and a process you and your team likes.

Different processes describe different practices to adopt and use. Many tests for good process usually assess whether you’re following the process or not, which doesn’t necessarily mean you’re delivering software people like or that you prefer to work that way.

So, to perform a quick properties-based health check on your current approach, grab a group of your team members, sit down together in a room, and discuss these properties. For each property, ask the team to rate it on a scale of one to five—five meaning you’ve got lots of that property, one meaning that property doesn’t exist for your group at all. Sometimes I use grade levels A through F. Then when looking across properties, I come up with a handy report card.

Jeff Patton

http://www.stickyminds.com/s.asp?F=S15474_COL_2