NJ Geeks - New Jersey's IT Community

As I promised, here is the presentation from Tuesday night's Northern New Jersey .NET User Group.  

 For those of you who didn't attend, the N3UG hosted Speaker Idol, which is a small competition where developers give a short 15-30 minute presentation in which we are judged and critiqued.  I particularly enjoyed Miguel Castro, who did an excellent job of playing the Simon Cowell role.  Best of all, he rewarded all contestants with a license of CodeBreeze, a code generation tool for .NET.  ­

­

UPDATE: I got tired of looking at my original stupid title, "CompSci - Math = Big Mac - Secret Sauce". Clearly, my original title was mathematically flawed. :)

Want to be a computer scientist? Forget maths

I've been reading this headline this past weekend and I'm shocked. Actually, I'm a little indignant and frustrated because I recently came to the exact opposite conclusion not too long ago.

Before I continue, let me add the disclaimers.

DISCLAIMERS: I did not RTFB, and I'm not attacking the author's ideas as I haven't read the book. I'm very hopeful the author's main thesis is not that math is irrelevant, but that we've all missed an fundamental concept that's even more important.

I've been doing a lot of reading and writing about the nature of programming languages and how the relate with our spoken languages and I have identified some strengths and weaknesses between our spoken tongue and machine languages.  While it's easy to enumerate the differences, there are a few differences and similarities that interest me in particular.

1. Both are made up of words consisting of verbs and nouns at the minimum.
2. Machine languages tend to require definitions up front.
3. Vague statements are tolerated in spoken languages as their meaning can be elaborated later.

To further appreciate the similarities between the two languages, I've been doing little exercises where I try to translate both contrived and randomly found sentences into a familiar syntax and made up syntaxes.  Here is an example of my exercises:

In case you haven't heard, JavaScript is actually being recognized as a powerful language these days, as it possesses powerful Lisp-like qualities. Two features, closures and lambda functions (anonymous functions) are a few key elements behind this power.

To demonstrate this power, I'm going to create some JavaScript code that allows a programmer to easily create JavaScript classes at runtime. I mean classes, not objects. For example, wouldn't it be nice to have a function like this...

function person(first, last, age) {
  this.first = first;
  this.last = last;
  this.age = age;
}
var Bob = new person("Bob", "Jones", 23);

...converted into something more concise like the example below?

var person = make_class("first,last,age");
var Bob = new person("Bob", "Jones", 23);

  Some of you are aware that the .NET Meetup is a weekly meetup where we get together to talk and code.  Recently, we decided to open up our meetup to make it more agnostic and invite anybody in who likes to program and wants to hang out with other geeks and work on small projects or puzzles.

  So, we created a Hackfest.  If you live near Northern New Jersey, like to program or work on small projects, then sign up and RSVP.  We meet every Monday in Paramus at the Panera Bread on Rt 4 near David's Bridal (Across from the Bergen Mall).  In the first few months, we've been average 6-7 people which is very good for a meetup this young.

Not too long ago, I formed the .NET Meetup so I could meet other .NET local developers, learn a few tricks, and work on improving my .NET skills.  We've been meeting weekly, and until recently had a very loose agenda where we were supposed to form ad hoc groups and work on projects.  Unfortunately, that didn't work too well insofar as even self-organizing teams need structure.  That led me to conceive of something I call Pair-Programming Shu-Ha-Ri, based on some of the concepts of pair-programming and Martin Fowler's write-up on Shu-Ha-Ri.

Tonight we put the idea into practice, and I think it went pretty well despite the lack of Masters/Guides.  The main goal for the evening was to be productive and pass down knowledge and technique, and from the feedback I got, I think that was accomplished.  We broke up into two teams where there were two students/laptop and a guide for the team.  Each team brain stormed an idea, and the master guided the team to breaking down the idea into clear defined goals.  Each team then created a mock-up and some of the teams got started on writing unit tests using NUnit.

From talking to the novices, they seemed to appreciate how the session focuses on the Master showing the Student how to be productive using the Master's methods.  Concepts are explained when necessary, but only enough to complete the task.  There are better ways to learn concepts, these sessions are all about learning technique.  A number of the Students never used NUnit or had done test-driven development before, and a few mentioned they will be doing more test-driven development with NUnit in the future.

I'm looking forward to the next session, but I would like to see more Masters/Guides come out so the teams are more of a 1-on-1 experience.

  My friend Dossy introduced to Shu-Ha-Ri sometime in the last year.  From Martin Fowler's blog, he says, "Shu-Ha-Ri is a way of thinking about how you learn a
technique."  The idea is a student should go through 3 phases when learning something new. 

• Shu involves doing exactly what your master tells you to do so you learn his technique.
• Ha involves branching out, learning new techniques and focusing on the theory.
• Ri is where the student doesn't learn from a master but branches out on his own and learns from his own experiences.

   We started a weekly studying/coding group a month back and it's already grown to 7 people.  To help the group be successful, I started thinking it might be a good idea to incorporate a little ShuHaRi into our little session, but adapt it to the principles behind Pair Programming.

Pair Programming Shu-Ha-Ri Rules

1. Break up into teams comprised of 1 experienced developer (Master) and 1 less-experienced developer (Student).
2. The Student sits at the keyboard, the Master will dictate to the student what to do.
3. The Student is responsible for setting the agenda.  He tells the Master what he wants to work on (Task List, Web Crawler, etc.). The task can be something he worked on over several weeks, but it should be small.
4. The Master will break up the Student's goal into small workable pieces.  The Master will break these pieces up into very specific and small realistic goals that can be accomplished in an evening.
5. The Master will guide the Student to finishing the goals for the evenings and the Student will do it in the way the Master tells him.

This month Martin will be leading us into a discussion about a few MySQL topics, some which may include a presentation: