RSS
Facebook
Twitter

Thursday, March 24, 2011

DSL presentation at the local Software Craftsmanship group

A couple of days ago I gave a talk at the local Software Craftsmanship group on the subject of Domain Specific Languages (DSL) and fluent interfaces. After the session I prepared an exercise for the audience:
Create a fluent interface for an online shop that calculates discounts based on customer and purchase information.
I gave a list of use cases and waited to see what would happen:
  • VIP customer get 15% discount on all purchases
  • Buying product A would give you 10% discount on product B
  • Preferred and VIP customers can buy 5 + 1 of a specific product
  • All customers can get 20% off purchase using specific coupon
  • If amount of purchase > 100$ customer is entitled for 10% discount.
  • If customer have purchased > 100$ the last three months upgrade him to VIP
  • On the customer’s birthday he’s entitled to 50% discount
  • All customers living in New York can get up to 25% off all purchases
I was expecting API along these lines:
RuleEngine.CustomerOfType<VIP>().GetDiscountOf(15);
The group was divided to teams of 2-3 developers choose a programming language and started working on my exercise. The first thing I’ve noticed is diversity in programming languages – C#, Java, C++ (on Linux!), Python and Ruby were used.
After a while it has become clear that the room was divided into two main groups of thought. Some teams started to design the object model required to solve the problem while other teams started implementing the rules and created the fluent interface from the required rule. This made me think about upfront design vs. iterative development. No one managed to complete the entire exercise but the teams that choose to design up front managed to cover less rules than the teams that created the rules one by one.
It was fun watching teams designing an API and then finding ways to create the API they wanted. I saw some interesting implementation ideas that were very different from what I had in mind in a good way.
All in all it was a good meet-up I can’t wait for the next time.
Domain specific languages

Update
The session (in Hebrew) can be viewed here - thanks to  Uri 

SCIL.DSL from Uri Lavi on Vimeo.

Thursday, March 17, 2011

Advice for the newbie developer

Every developer was a newbie once. It doesn’t matter if you’re fresh out of college or been developing software for 10 in this line of work you get to be the newbie from time to time – whenever you learn a new technology or programming language and to some extent whenever you start working in a new place.

Lately a new member has join our team. Her is a capable developer with years of experience under his belt, he is also completely new to the .NET world. Luckily he has the right attitude and he’s willing to learn everything from scratch - fast.

the following is my advice to the software developer who wants to learn created from observations of the last few days:

Admit that you’re a newbie

This on isn’t trivial – in order to become a seasoned developer you have admit that you’re not there yet. This becomes harder as you become a more experienced developer. although you can use old knowledge in order to learn new stuff quicker more often than not you need to start from the bottom. a seasoned C++ developer would probably learn C# quicker than someone who never wrote a single line of code but it does not mean he automatically knows everything.

Be willing to leave your comfort zone

This is the prerequisite to learning new things. You might be used of doing things using tools and practices that does not apply to the new technology. Instead of forcing your beliefs and methods where they don’t belong you need to learn new  ways of doing things. The plus side is that you might learn something that would change the way you think.

Find a mentor

Although this point is not mandatory, it helps when there’s someone to learn from. Find your mentor and ask him questions. It could be your team leader, another team member or your friendly neighborhood architect. It doesn’t matter as long as he’s willing to teach you. He would help you avoid the same problem he already solved and teach you new tricks specific to your project sometime without even noticing.

Keep an open mind

Change is hard, Learning new stuff is hard. Try not to be the obstacle to your own learning. It’s easy to explain why your old way of doing things is better than others and what’s wrong with everything around you (and that prices were reasonable, politicians were noble and children respected their elders). The point is that you need to learn – so why not try something new, the worst that would happen is that you learn not to do it anymore.

Don’t take anything for granted

Ask questions, not just to learn but to understand why things are done. Just because you’re new it doesn’t mean that you cannot teach as well. People get used to doing things a certain way that might be changed due to a fresh perspective.

Conclusion

That’s my thoughts on the subject – I hope it helps the next time you have to learn something new…

Wednesday, March 09, 2011

How I Learned to Stop Worrying and Love the Coding Convensions

Can you spot the difference between the following two code snippets?

Exhibit #1:

public class MyClass
{
    public int MyFunc(int x, int y)
    {
        return x + y;
    }
}

Exhibit #2:

public class MyClass{
    public int MyFunc(int x, int y){
        return x + y;
    }
}

If you have some programming experience you might recognize the two styles. One of which common in your projects and the other looks strange and might even cause you a slight discomfort or bad feeling at the pit of your stomach. Some software developers have been arguing about which is better for as long as I can remember and to tell the truth I was one of them until recently.

I work mostly in C# and the majority of projects/demos/tutorials out there use the first convention. I used to argue that it’s better because it makes the code more readable and besides that’s the Visual Studio default and if it’s good enough for Microsoft it’s good enough for me. Then I got to my current employer where the official coding standard defines option number 2 as well as other conventions and it was hard. Each time I glanced at my code I had the urge to re-format, it made me feel “dirty”. After a while I got used to the new curly brackets location but it still felt wrong to me. One of my responsibilities is to make sure that all of the teams projects follows the official company’s coding specifications some of which I don’t fully agree with.

I’m a fan of this developer’s life podcast and yesterday I heard the latest show Obsession where Scott and Rob talk to several developers about their obsessions and than it hit me – the feeling I have whenever I see code that formatted “wrong” is my little OCD (obsessive compulsive disorder), it’s one of the obsessions I picked up on the way, I need to code to be “right”, similar behavior can be found when developers argue what is better – camel-case or Pascal-case, spaces or tabs, VB.NET or C# and so on. Many of these arguments are valid but sometimes we just miss the point, just because we feel good/bad with something doesn’t mean that it’s right it just mean we’re more comfortable with it and that’s ok.

As for coding standards there is a valid reason  they’re in place – we want all of the company’s source code to follow the same rules. An important goal – even at the price of making you feel good about how the code looks.

One final note – this can only go so far, if the rules make the code less readable and the developers less effective – you should make an effort to change them.

Happy coding…

Related Posts Plugin for WordPress, Blogger...