pr0g33k

 collapse all
  1. Learning Knockout.JS

    Learning Knockout.JS

    My video course, Learning Knockout.JS, was released on August 31, 2015. I hope that you will check it out. I had a lot of fun making the course and I think it turned out really well.

    Among the various JavaScript libraries available to developers, Knockout.JS really stands out due to the diverse features it provides and also because it promotes the use of the Model-View-ViewModel (MVVM) design pattern to build data-driven web applications. Construct power-packed apps without compromising on its flexibility and build rich user interfaces, which will update in real-time when the data model state changes, eliminating the need to refresh pages.

    Learning Knockout.JS will walk you through all of the key features of Knockout.JS and make it easy for you to quickly and easily build feature-and data-rich web applications that are easy to extend and maintain.

    We start off with a brief introduction to Knockout.JS, and its various benefits, and explore the different design patterns in context of Knockout.JS to make your JavaScript code cleaner and more manageable. After that, we will walk through and understand the relationship between Models, Views, and ViewModels, as well as creating them.

    Along with that, you will also learn how we can use the different data binding attributes to manipulate the output. We will also discuss and implement various important concepts such as two way data binding and dependency tracking to update your UI in real-time and to separate the components of your application into logical parts.

    We will analyze Knockout’s template feature to help you deal with data context in most scenarios. Then, we will take a look at how to track the changes in dependencies and subscribe to them using computed observables and subscriptions. Furthermore, you will also learn how to customize bindings and functions as well as using extenders to create our own set of Knockout tools. Finally, we will take a look at some advanced features of Knockout.JS to take your knowledge to the next level!

    Learning Knockout.JS is more than just an introduction; it’s a complete course on one of JavaScript’s innovative libraries.

  2. Web App Testing Using Knockout.JS

    Web App Testing Using Knockout.JS

    I was very pleased to serve as a reviewer on this book. It is very well-written and is packed with a ton of useful information and practical techniques. The Knockout.JS sections are very clear and approachable to beginners and advanced developers alike. The book especially shines when it comes to unit testing Web apps using Jasmine and the sections on Node.JS, Gulp.JS, Karma, and Phantom.JS are equally impressive.

    Using the libraries and techniques described in this book have definitely improved my daily development workflows. I highly recommend this book!

  3. Applied Architecture Patterns on the Microsoft Platform

    Applied Architecture Patterns on the Microsoft Platform

    Earlier this year, I was invited to be a technical reviewer for Packt Publishing. They recently published the first book I reviewed for them, Applied Architecture Patterns on the Microsoft Platform.

    Many of the patterns books I've read have been pretty dry and sterile. Not this one! The authors really make the content come alive with practical examples and realistic use cases. They also cover several emerging technologies such as Azure, Workflow Foundation 4.5, and Multi-master Sync.

    If you're in a position where you have to make enterprise-level architectural decisions - or if you want to be in that position - this book is a must-have. In most of the chapters, the authors present common use cases and then discuss several different Microsoft technologies and how they can be used to address the situation. Each technology is weighed by their pros and cons and then graded based on several criteria. The technology that would best work is then employed and sample code is given. It's very instructive to witness the decision-making process in this way.

    I definitely recommend this book. It's well-written, concise, and insightful.


    Packt Publishing has a plethora of wonderful technical books in their inventory. They also sell their publications as eBooks in several different formats which I definitely appreciate (I read so much more now that I have a Microsoft Surface and can store all of my books in one, convenient place).

  4. Accidental Learning (Redux)

    I'm catching up on Entity Framework so I'm reading Julie Lerman's excellent books: "Programming Entity Framework," "DbContext," and "Programming Entity Framework: Code First." For grins, I Googled her using Bing and found this gem on her blog.

    It's also interested me to consider how this process, repeated over the years, has resulted in my having a quiver filled with a slew of little bits of very useful, somewhat scattered, information. This is very different than learning a big topic, like testing or Entity Framework. However they are a starting point at which I can leverage the tool and make it work for me.

    I mentioned in my last post that our brains are great for long-term storage for things we do frequently but no-so-great for things we've only done once or twice. Like Julie, I have tons of scattered information about a wide variety of topics - just enough to make me dangerous - and thousands of lines of code I've written over the years that serve as an excellent resource when I come across a new problem that's similar to one I've already solved. I completely understand what she means by these pieces of information and little snippets of things we've done in the past being leveragable tools for getting things done.

    My recent string of interviews has been a really defeating experience. There's nothing quite like sitting in front of someone who seemingly holds my career in their hands as they pound me with questions on the inner workings of SQL Server or ask me to diagram a game of five card draw on a whiteboard using every known design pattern. Index tuning and UML diagramming are things I've done in the past but were done infrequently and sporadically. Recalling them (or, rather, in the interviews I've had recently, not recalling them) has been challenging and has really made me question a 15-year career in programming.

    On the other hand, my recent string of interviews has also been a really great learning experience. I've been in somewhat of a vacuum the past 12 years by working in one industry/market and on very small development teams extending a single product. As a result, I've missed out on some of the methodologies and technologies that have gained favor in the past few years - namely Test-Driven Development (TDD) and Entity Framework. Now that I know I have some deficiencies, it's time to get to work and fill those knowledge gaps.

    Reading Julie's post made me realize that I'm not the only one that has learned a wide variety of things - if even accidentally - and has become a "jack of all trades, master of none" developer (though she has written three books so I'd consider her a master at Entity Framework). It's nice to know I'm in good company.

  5. I'm smart and I get things done.

    I've been interviewing for a new job over the past several weeks. In the past, I've gotten jobs through contacts and word-of-mouth but now that I'm branching out to other industries, I'm finding the job search to be really tedious.

    "That's the trouble with the world today. No one takes the time to do a really sinister interrogation anymore. It's a lost art."
    ~ James Bond, Goldeneye

    Trivial Pursuits

    Over the past several weeks, I've been somewhat perplexed about whether I'm being interviewed for a job or participating in an episode of "Jeopardy!". Five of the seven interviews I had last week were solely trivia tests. "What is the MVC pattern?," "What properties would you set when using jQuery to make an AJAX call?," "What is ACID in the context of databases?," and "What is the difference between a primary key and a unique constraint?" were just a few of the questions I was asked. These questions are great for a college pop quiz but do little to determine someone's experience, intelligence, or talent.

    For example, at one of my first tech jobs, the CTO hired someone that could answer absolutely every technical trivia question he was asked. The guy was a machine. Without blinking - without even waiting for the interviewer to finish the question - he spat out the answer with textbook accuracy. "This candidate is amazing!," we were told. "You're really going to learn a lot from him." He was fired a few months later because of a total lack of performance on the job. He couldn't write a line of code to save his life. (After the first week, I seriously wanted to put that metaphor to the test, too.)

    Interviews disguised as trivia contests give me some insight as to the type of company and employees with whom I would be working. If the interviewer doesn't want to get to know me and discover what makes me tick, then I probably don't want to work for them. I'm at least going to be wary going into the next phase of the interview process or when it comes time to accept an offer.

    "Reality is merely an illusion, albeit a very persistent one."
    ~ Albert Einstein

    I've only had one interview so far where I was asked to write some code. I was initially excited when it was explained that the test had three parts: SQL, C#, and UI (HTML5 and jQuery). I anticipated that I would be given a business problem to solve and that I would be designing a simple database schema, writing some data-retrieval code and some business logic, and displaying the data in a Web application. These are simple tasks that I perform every day and would be a great way to show how I organize projects and solve common problems.

    If only...

    For the SQL portion, I was asked to write two simple queries based on a schema diagram they provided. I nailed both of those without any problem so I was off to a good start!

    For the C# part of the test, I was asked to examine code similar to this:

    public class Program
    {
        static void Main(String[] args)
        {
            Int32[][] array = { new[] { 1, 2, 3 }, new[] { 4, 5, 6 }, new[] { 7, 8, 9 } };
            Console.WriteLine(GetValue(array));
            Console.Read();
        }
    
        private static Int32 GetValue(Int32[][] array)
        {
            return ProcessValue(array, array.Rank, array.Length - 1, 0, -1) - ProcessValue(array, 0, 1, array.Length - 1, 2);
        }
    
        private static Int32 ProcessValue(Int32[][] array, Int32 x, Int32 y, Int32 w, Int32 z)
        {
            return array[y - x][w - z];
        }
    }
        

    Without running the program, I was asked to solve the output. "This is to see if your brain can serve as a compiler," I was told. Thankfully I was given a piece of paper and a pen. I spent an equal amount of time working on the problem as I did debating in my head whether I should politely excuse myself walk out. Ultimately, I didn't get the correct answer; I was off by 1. Based on that, I failed the interview and didn't get the job. Thankfully! If my days there were to be spent "compiling" code in my head and solving inconsequential puzzles, I would have gone insane and quit within a week.

    To make matters worse, this particular interviewer stood two feet off my left shoulder and watched every keystroke. I had to wonder if he was going to do that once I was hired. If that isn't their normal work environment, then why test me in such an environment? If a test isn't based on reality, then why administer the test?

    Build an atom bomb to prove you can make a firecracker.

    I have no problem with being asked to write a little code to show that I have at least some basic understanding of programming. It's important to make sure a candidate knows the fundamentals of looping and conditional logic, for example. One of my favorites is the "FizzBuzz" problem:

    Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".

    A problem like this is simple, can be solved in at most 10 to 15 minutes and is a good indicator that the candidate isn't faking their understanding of basic programming.

    Incidentally, the result could look something like this:

    for (Int32 i = 1; i <= 100; i++)
    {
        if (i % 3 == 0 && i % 5 == 0)
            Console.WriteLine("FizzBuzz");
        else if (i % 3 == 0)
            Console.WriteLine("Fizz");
        else if (i % 5 == 0)
            Console.WriteLine("Buzz");
        else
            Console.WriteLine(i);
    }
        

    Anything more complicated than that is superfluous. Asking a programmer to write a complex application for you during an interview is like asking an electrician to build an electrical grid for you before they replace a lightbulb.

    We're looking for a developer, just not a resourceful developer.

    How many developers do you know that have never had to rely on a resource to solve a problem? None, you say? Then why would you limit a developer you're testing by excluding the use of resources? Every single technical test I've taken during an interview disallowed the use of any resource during the test. Here's a thought: why not blindfold me and and tie my hands behind my back, too?

    The human brain is incredible in the way it can store vast amounts of information. However, it is limited. For repetitive things, our brains are awesome at long-term storage. For things we've only done once or twice? Not so much. For those things, I rely extensively on a much more reliable storage mechanism: hard drives. My laptop is filled with code samples I've written over the years. When I encounter a complex problem that I've solved before or a problem similar to one I've solved before, I reach for that code; I adapt it to the current problem. If I had to struggle to reinvent the wheel for each and every problem I encountered, I'd rarely meet any deadline.

    There's another resource I use which, for whatever reason, interviewers always want to disallow: the Internet. This makes no sense whatsoever. Searching the Internet for the solution to a problem is, in many ways, an art form and it's a skill that every developer must have in their arsenal. What a developer does to find the solution to a problem should be part of the test!

    You should want developers who are resourceful. You should want developers who can learn. If you don't, then I'm not a good fit for your organization.

    The Pragmatic Passionate Programmer

    The two interviews I had last week that interested me asked questions like:

    • What was the most interesting part of the last project on which you worked?
    • What is the most recent technology you've learned, why did you want to learn it, and how did you learn it?
    • Why did you choose to use technology X over technology Y in your last project?

    These questions explore the two most important traits of a good programmer: the ability to learn and a passion for the craft of programming.

    That last question, though, really bothered me at the time. You see, I explained to the interviewer that I was the chief architect and lead developer on my most recent project. The project was your standard 3-tier architecture - SQL Server dababase, business layer/ORM, and a Silverlight front end. The ORM I chose to use was my own which is based on Martin Fowler's excellent "Patterns of Enterprise Application Architecture." It has been continually developed, enhanced, and maintained over the past 12 years and has proven to be very successful in every project where I've used it. The interviewer questioned why I used my own ORM instead of a commercially-produced ORM like Entity Framework or an open-source ORM like NHibernate. I explained that I had evaluated those ORM's and had to consider that the team I was tasked to lead had little OOP experience and that my ORM was very direct and simple to use. "Well, I think that was a mistake because if you use a commercial product or something that's community-driven then you get the benefit of a large group's expertise as opposed to just one person and you also have the benefit of regular updates and enhancements from the community," she said. We hotly debated the pro's and con's of my decision and, in the end, agreed to disagree. (Toward the end of the interview, she actually apologized for being so openly hostile toward me.) At the time, I was irritated that she was so quick to dismiss 12 years of hard work without ever having seen it. Now, however (though I don't think it was intentional on her part), I see that it was actually a really good interview technique. She was able to get me to show passion for my work, my love for programming, and an ability and willingness to defend my decisions in spite of the desire to please her just to get the job.

    Would you hire a chef without first tasting his food?
    Then why would you hire a programmer without first having seen his code?

    I have yet to be interviewed for a position where the interviewer has asked to see a sample of my work. This is really disappointing. When I was a hiring manager, I would ask the candidates to bring their laptop (or at least print out some code) so that I could see something that they've written of which they're particularly proud. Once it was in front of us, I would ask what was the business problem that was solved. I would then ask for them to walk me through the code. I could usually get a good sense of the type of developer I was interviewing. I could see the way they formatted code - did they care enough to make it pretty; did they name classes, methods, and variables in such a way that the code was self-documenting; did they organize the project in a way that others could easily pick up the project and work on it, etc. I could get a sense of their thought processes - did they approach the problem in a logical manner, did they think in an object-oriented or procedural manner, etc. Most importantly, though, I could get a sense of their passion for solving the problem. If the candidate became animated and excited about what they were explaining to me, that candidate was a contender.

    Smart and Productive? You mean you can have both?

    Joel Spolsky has two criteria for hiring a good developer: you're looking for people who 1.) are smart and 2.) get things done.

    People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say, “Spreadsheets are really just a special case of programming language,” and then go off for a week and write a thrilling, brilliant whitepaper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful. The other way to identify these people is that they have a tendency to show up at your office, coffee mug in hand, and try to start a long conversation about the relative merits of Java introspection vs. COM type libraries, on the day you are trying to ship a beta.

    People who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. This makes them net liabilities to the company because not only do they fail to contribute, but they soak up good people’s time. They are the kind of people who decide to refactor your core algorithms to use the Visitor Pattern, which they just read about the night before, and completely misunderstood, and instead of simple loops adding up items in an array you’ve got an AdderVistior class (yes, it’s spelled wrong) and a VisitationArrangingOfficer singleton and none of your code works any more.

    Conclusion

    So if you're thinking of interviewing me for a position at your company, please take these ideas into consideration. Please ask me questions through which I can demonstrate that I'm smart and that I can get things done. If you only throw "Aha!" questions at me or ask me to solve trivial brainteasers, don't be surprised if I politely excuse myself and never return. You see, I'm interviewing you just as hard as - if not harder than - you're interviewing me. You're looking for a good employee but I'm looking for a good employer.