A small developer-oriented PowerShell wish list

I have just started to use the PowerShell a few days ago; and I am more and more impressed by the work that have been done by the MS folks. Yet, being a developer, I have the feeling that many aspects of PowerShell still need to be polished. Too bad that there is no Visual Studio project templates for CmdLets. Providing an hello-world CmdLet with its associated SnapIn would really make the life of the developers easier, smoothing the learning curve.

Let's get cosmetic on C# documentation

I am gathering here just a few C# documentation cosmetic tips that I apply in my own projects. I do not pretend to have achieved any absolute truth or any optimal practice with those tips. I just find them convenient when applied with consistency. #region #endregion directives can be great, but caution not to overuse them by putting a dozen of directives within a 200-lines long code file. Indeed, if region makes the code structure more apparent, region also makes the code less proofreadable because you have to open the regions to actually start reading.

Blogosphere quatitative elements, a few slides

Being part of the Corps des Telecoms, I have been assigned for a modest blog study within the scope of a communication course. I have found the subject highly interesting because blogs open whole new directions of research and whole new methodologies. Indeed, contrary to most usual communication events (ex: person-to-person talks), it’s potentially possible to retrieve most of the blogosphere content through web crawling intensive methods. The slides of the talk have been uploaded.

ResxEditor reloaded - version 1.2 released

They were a couple of long standing issues with ResxEditor. Most of them were actually reported as comments on the blog post of the initial ResxEditor release. All of those issues are now fixed. Bug fixes and new features are detailed on the ResxEditor page. Special thanks to Nick Pasko for carrying most of the work and finding a solution to get rid of the previous cell saving behavior that was driving translators nuts.

Finally, I am going to be a theology teacher

According to Jeff Atwood (Coding Horror), software development is a religion. Wow, frankly I hope not, because I am quite ignorant when it comes to theological matters. A major issue with human/social studies and practices is that it is so hard to get close to anything that would be considered as scientific knowledge and not pure erratic opinions. Yet, it’s not because it’s hard to produce science that it isn’t worth trying.

Wiki misuses (collaborative tools, part 1)

Great software development requires great tools; but tools do very little in themselves if the craftsman lacks the proper skills. In my (limited) experience, I have noticed that collaborative tools are often extremely useful (i.e. provide strong productivity boosts) while also being quite hard to master. There are far too many collaborative tools to discuss for a single blog post; I will start with the wikis. Why do you need a wiki?

Typo hunting: get some weapons first!

It’s just too hard to spell check your text by hand (or it requires an unreasonable amount of time). Before you actually get a spell checker, you might not even realize how many typos you produce. I have just downloaded today the FireFox RC1 that includes a web form spell checker. My first target for typo hunting was an intranet wiki I am working on. I feel that I won’t ever go back to a browser that does not provide such a feature natively.

The unteachable parts of software engineering

Having the responsibility to handle the software engineering course at the ENS in spring 2007, I have started to think about the desirable qualities that make the difference between an average developer and a brilliant one. Indeed, I can’t think of a better goal for this course but to actually try to develop such qualities. What makes a “good” software developer? It’s an obvious fact that many qualities and skills are required to make a good developer.

Your e-mail is your username

The 30-years-old unix pattern for user management involves a UserName, Password pair associated to a unicity constraint on the usernames. On most web applications, this pattern has been enriched as a triplet UserName, Password, Email with, usually, a two-fold unicity constraint both on usernames and on emails. But is there any good reason to distinguish e-mail from username? By looking at the major web players (Google, PayPal, Amazon …), the answer is negative without any doubt.

Antipatterns of Software engineering courses

I am very honored to be in charge of the Sofware engineering and distributed applications course at the Ecole normale superieure (ENS). This will be my first official teaching assignment, and I will be affected to brilliant Licence 3 students (it’s pretty tough to get through the entrance exam of the ENS). Software engineering is a difficult topic to teach. I have been browsing the web just to have an outlook at what people are usually doing in a software engineering course, and I must confess that I haven’t found anything very satisfying so far (although the MIT experience is definitively worth reading).