Yesterday evening I did an Introduction to TypeScript at CRineta. I agreed to do it on short notice, so I scrambled to pull the talk together over the weekend. Much of this version of the talk was based on Anders Hejlsberg’s Build 2014 talk. And of course I used the resources from typescriptlang.org along with TypeScript in Visual Studio. I’ve had a small amount of TypeScript code in production for about 6 months, but I’m going to start converting more now that 1.0 is released.
What is TypeScript?
“TypeScript is preview of EcmaScript 6 with a downlevel story and with static typing on top” – Anders Hejlsberg
The TypeScript Playground is a great place to start testing TypeScript.
Their tutorial is of limited value, but the Handbook gives you a compact view of the language features and is very useful.
And of the course the language spec is available as well.
Anders Hejlsberg at Build 2014 – http://channel9.msdn.com/Events/Build/2014/3-576
Luke Hoban at Fluent Conf 2013 – https://www.youtube.com/watch?v=5UPMqtrbw7E
One aspect of my current job that has been rewarding is getting to train and mentor other people in my group. Years ago I did technical training as my full time job and I did reasonably well at it, but I learned that doing it full time wasn’t where my interest was.
Training and mentoring as a part of my full-time software developer position is more rewarding because I get to keep my fingers in code much of the time and am still able to invest in others in my group by teaching them skills that are necessary for our department to operate well.
Today I worked with a more junior developer teaching him how to really think about Mercurial and distributed source control. He’s been able to do basic push, pull, commit and summary commands for over a year, but he’s never deployed to production. So we walked through how to think about merges and how to read the TortoiseHg graph so he could see what happens as he goes to other branches, merges, commits and pushes his changes. After about 30 minutes of explaining the metaphor and the terminology, he started running with it on his own.
Over the last 5 years I’ve trained three graduate students to work on our web projects. Two students I trained for a year and another I trained for 2 1/2 years. They each started on our web projects with a wide range of skills and abilities. So the key was taking them where they were at and giving them the right amount of space and information to grow as fast as they could handle learning.
I have to admit that it can be a bit exhausting investing in people at that level and still developing software full time, but it is very rewarding to see them be able to use those skills in other settings and move onto other jobs.
In all of my future work I want to keep developing my ability to train and mentor others.
It can be easy to snipe about bad or mediocre interview experiences I’ve had. So instead I’ve been thinking back to what really worked with past interviews.
One company from my past that stands out regarding the interview process is MetaCommunications here in Iowa City. If I recall correctly it was split into three phases. We ended up talking over the phone at first to see if there was mutual interest, but that wasn’t part of the process.
Also, when I say that it was done well, I’m not saying that it was done well because I performed well. I’m saying that it seemed to give the person being interviewed the best chance of being able to show their potential, how they go about solving problems and how they interact with others.
The first phase of the process was mainly a meet and greet to get to know each other. I went into their offices to see where they worked. There is nothing unique here, but it is a nice touch to take the pressure off and it’s the first logical step with any employment relationship.
The second phase was on a different day and it was the core of the technical interview process. I was given a computer with Visual Studio and asked to do a couple of tasks. One task was to implement a puzzle in C#. During the process I could ask questions, look stuff up and they could observe how I went about things. I forget the specifics of the second task but it had something to do with building a validation system in ASP.NET MVC.
The first task I did relatively well on and the second I performed so so. But instead of the interviewers being on the high ground and me just having to defend what I know over a phone, we were on equal footing, face to face and I was using a tool I was familiar with. We were interacting somewhat like if I were actually in the job. I strongly believe that this types of interaction gives both sides more accurate and far more information about if the position will be a good mutual fit.
The third phase was on another day and it was primarily about negotiating a salary and deciding when to start. Once again this is an important phase but it is pretty standard.
Spreading the process into 3 interviews gives some time for both sides to consider what is happening. It also puts them on equal footing, so they know who they might be working with.
Some employers might balk because it takes them out of the perceived position of control in the interview. To them I would say that even though this is true, they still will get better information on how the person interacts, better information on their technical skills and if they would be a good fit in the company.
Others are going to balk because they have to spend more time interviewing people. Yes, and it’s worth it. Finding the right people and not artificially weeding them out is critical to your business.
And others may say that the process doesn’t scale. It is more costly time-wise, but once again it is the one method I’ve seen that has been the most fair and provides both sides with the data they need to make better decisions in hiring.
Years ago I was interviewed by a someone who really liked SQL Server and they liked SQL Triggers in particular. So we started the interview and they asked me a question about triggers and I unashamedly deferred since I knew what a trigger was but hadn’t been using them. It’s something I could easily look up as soon as I actually needed the knowledge.
We moved on but they decided to keep asking me questions about triggers and finally some other SQL topics, almost dumbfounded that I didn’t have this kind of knowledge packed away in my head. I ended up taking that job, but knowledge of triggers played almost no part in my success there.
They thought the questions that would shed the most light on my ability were trivia questions about syntax and such. There is nothing wrong with someone who can tell you the ins and outs of T-SQL, C# or some language, but that kind of knowledge doesn’t tell you if the person can deliver a good product or feature in your code base.
If your interviews are primarily trivia, you are mistaking what a software developer does. You probably think that a developer spends the bulk of their time writing code, when in reality they spend far more time thinking, talking, drawing and planning than they do actually writing code (at least this has been my experience).
You want to hire someone who can interact in your environment and can make good judgement calls about how to design a product, can talk with a client or can add new features to your product. If your focus is on questions like “do they know the syntax for creating a trigger” you are missing the more foundational questions that could actually tell if you if you want to hire the person.
If you want to know their technical skills, have them code in an environment that is familiar to them. Don’t ask them to write a C# in a raw text editor. If your shop uses Visual Studio, give them an exercise in Visual Studio or at least let them pick the environment of their choice. What you are looking for is how they go about solving problems. Do they ask questions at the right time? Can they lay out an algorithm? Do they use any tools or techniques to validate that their design is good and produces valid output? What information do they look up and what do they just know?
If you ask trivia questions in an interview that is fine, but don’t stop there or you will miss evaluating your candidate’s most important abilities.
Microsoft made a big move recently by supporting Mercurial on Codeplex. The company I was working for in 2009 was contemplating moving to a DVCS (Distributed Version Control System) and had we made the move, we would have gone to Mercurial. So I’ve been using Mercurial off and on for the last 8 months and have been pleased with the ease of use and the clean command set.
If you are just starting with Mercurial here are some basic commands that will get you going. For the sake of this article, I’m going to use Orchard as the example repository.
-Orchard source url: https://hg01.codeplex.com/orchard
-Clone repository: hg clone https://hg01.codeplex.com/orchard
-Clone repository (named working directory): hg clone https://hg01.codeplex.com/orchard my_dir
-Pull source from remote: hg pull -u
**Note: ‘-u’ is important since it updates your local working copy after pulling the latest
-Local commit: hg ci -m “some message”
**Note: Remember that you are committing to you local repository, you still need to ‘push’ to your remote repository.
-Push commits to remote: hg push
**Note: this command will likely request your credentials
-Check status of local files: hg status
-View the commit log: hg log
-View the most recent commit: hg tip
If you prefer to use visual tools then just type ‘hgtk’ at your command line and you will see all of the commands that will launch visual Mercurial tools. The following is an example for the visual log.
-View visual log of commits: hgtk log
If you have been using git or bazaar, then switching to Mercurial should be trivial.
What I’ve shown here is just the very beginning set of commands for Mercurial. If you want to dig deeper, then you’ll want to read the Hg Book.
A couple of weeks ago I was writing some code to initialize List<T> but my technique was very verbose and it seemed to be a distraction from what I was trying to do. Plus it seemed that every one else was writing about getting their func on.
So I looked back at some code that Nick Parker had written:
And tweaked it to initialize a list:
Now I can initialize a list like this:
Just for the record the Func initialization above could handle much more complex scenarios if needed. My usage is very simple.
Another variation on this is to create an extension method that does the same initialization like this:
And here is how you would use the extension method version:
Thanks to Nick Parker for some suggestions as I was working on this.
Something I would like to figure out is how to do this based on IEnumerable instead of IList. If you have ideas regarding implementing this on IEnumerable please add them as comments.
Also, if you want to see where I was using this, pull down the subversion source here: http://subversion.assembla.com/svn/solon-tools/trunk/Puzzles