As web applications become more common, more and more code is written in javascript. Automated testing and Test-Driving the server-side code is well-accepted, but testing javascript is still a bit of a mystery to a lot of people.
In this 1-day tutorial, we will build a browser-based application in javascript using a test-driven development (TDD) approach. We will use the popular JQuery javascript framework and the Blue Ridge javascript testing system. At the end of the day, participants will be able to
- Install and configure Blue Ridge
- Write tests using the ScrewUnit testing framework (bundled with Blue Ridge)
- Customize ScrewUnit, including writing helper functions and custom matchers
- Create test doubles for
- injecting test data into your functions
- setting method call expectations
This course will be hands-on, focusing on the practical considerations of testing javascript. Participants will be expected to have a general understanding of and basic experience using the principles of test-driven development.
Cost: $50 - $100 per person (still looking at this)
Class Size: 10 - 15 people
Project Date: August, 2010
Location: Most likely Chicago (since that is where I live)
This one-day course will focus on using TDD to develop a Ruby on Rails application with RSpec. We will start the day with “rails init” and end with a fully functioning application. We will highlight the basics of using TDD to drive out the design of your system while creating executable component documentation and a suite of regression tests. Along the way, we will cover topics including mocking, refactoring and evolutionary design.
Cost: $50 - $100 per person (still looking at this)
Class Size: 10 - 15 people
Projected Date: July, 2010
Location: Most likely Chicago (since that is where I live)
Software Craftsmanship is prevalent throughout the various software development communities and industries. However, opinions about and definitions of the term abound, both positive and negative, resulting in a confusing cacophony of voices to those trying to understand it. With such an explosive growth, it is sometimes hard to see through the hype.
Over the past year, I’ve traveled far and wide, discussing software craftsmanship with a diverse range of of people, hearing different thoughts on what it all means. While there are varying ideas on ‘software craftsmanship’, there is one recurring fundamental theme that stands out: helping developers improve their skills as individuals and as members of their community.
In this talk, I’ll cut through the hype and present an approach to the ‘craftsmanship’ analogy that can help guide us through our life journey in software development. More than just arm-waving, I will outline some of the concrete activities that some members of the Software Craftsmanship Movement are taking to help ‘raise the bar,’ both individually and as businesses.
Target Audience: Software developers who have heard the talk and are looking for how to walk the walk.
Software Craftsmanship is prevalent throughout the various software development communities and industries. However, opinions about and definitions of the term abound, both positive and negative, resulting in a confusing cacophony of voices. With such an explosive growth, it is sometimes hard to see through the hype, and focus on the fundamentals: helping developers improve their skills as individuals and as members of their community.
In this talk, I’ll cut through the hype and present about an approach to the ‘craft’ analogy that can help guide us through our life journey in software. Along the way, I will outline some of the concrete steps that some members of the Software Craftsmanship Movement are taking to help ‘raise the bar,’ both individually and as businesses.
Over the past year, the ideas of Software Craftsmanship have shown up in all the nooks and crannies of the various software development industries. Opinions about and definitions of the term abound, both positive and negative, resulting in a sometimes confusing cacophony of voices. With such an explosive growth, it is sometimes hard to cut through the hype, and focus on the fundamentals: helping developers improve their skills as individuals and as members of their community.
In this talk, I’ll cut through the hype and talk about an approach to the ‘craft’ analogy that can help guide us through our life journey in software. Along the way, I will outline some of the concrete steps that some members of the Software Craftsmanship Movement are taking to help ‘raise the bar,’ both individually and as businesses.
Go to solution explorer,
Find a binary (dll, exe) (in output directory)
Right-click, choose Open With…
Choose “Other Program” (or whatever it is called now)
Find Reflector.exe
Choose in Open With… dialog and set as default for dll,exe
Now, double-click from solution explorer, and it will open in reflector
Guess where I heard this:
Question: What does this…decision-making through abstraction layers do to the maxim of do all your design before you write any of your code?
Lecturer: Well… that’s someone’s axiom, and I bet that’s the axiom of someone who hasn’t implemented very large computer systems very much.
Me: Oh, Snap!
Yup, Structure and Interpretation of Computer Programs (SICP), with Ableson delivering the smackdown. I’m sad (on many levels), because I’m finding that all of my really cool ideas are encapsulated in the following quote (Greenspun’s 10th Rule):
Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp.
Except, replace “C or Fortran program” with “Corey’s Super Sweet Designs.” :)
Why am I sad?
I would think I would be sad because none of the stuff I had done was really new. However, on the other hand, this means that I’ve worked myself (through putting bunches of other ideas together) to make my way toward the ideas contained in LISP. That’s pretty awesome, if you ask me. Sure, it was informally-specified, not even close to half and probably buggy, but it was stuff I had fused together.
No, the real reason I am sad is that the SICP lectures are over 25 years old. Okay, they probably weren’t available digitally for a while, but the ideas must have been floating around in book, article and lecture form for many years before these videos were recorded. They have to have been, since the ideas are so well-formed. And, it isn’t just about big design up front; a ton of other ‘new’ ideas are in this stuff.
Okay, I wasn’t around back then, but I know a bunch of people who were. I’m going to find out what people’s opinions on this are. I’m going to people who were heavy LISP people and heavy FORTRAN people to find out where we lost this secret knowledge; lost it to the point where we are just discovering it again, rather than being introduced to it early.
And, as usual, I’m going to preemptively blame C++, as I do for most things.
What is it?
The ‘Pair with Corey Tour 2008’ is a trip that I’m taking during the first few weeks of December. I will be driving around Ohio, Michigan, Illinois and possible Indiana, spending 3-4 days in each location pair-programming with someone. I plan to leave towards the end of November, after Thanksgiving, and come back in the middle of December, before Christmas.
What’s the catch?
Well, my one requirement from those that I visit is that they provide me with a place to stay and feed me while I’m there.
Things should be placed according to what they represent, not where they are accessed. Putting things according to where they are accessed is equivalent to ‘just throw the thing in there’
Object-Oriented Techniques through Design Principles
Most OO developers are familiar with OO techniques, such as encapsulation, polymorphism, etc. But, not as many are familiar with general design principles, such as Single Responsibility, Open-Closed, Liskov Substitution, Law of Demeter, etc. And, if they are, sometimes it is difficult to see the connection between the base design guidelines and their implementation as OO techniques.
This talk will discuss standard Object-Oriented techniques as applications of the more general design principles, rather than as stand-alone laws. Attendees will come away with a better view of the ‘why’ behind the OO techniques, rather than just a set a rules to follow.
