The Ideal Work Term Progression for Computer Engineers, part IV

By Nicholas Armstrong | Published: August 23, 2009

With their Computer Engineering degrees now complete, my classmates (and I, in a sense) are now working at – or searching for – their first permanent full-time jobs.  Looking back on the journey that got us where we are, the one thing that stands out between my classmates is the experience they got while on their co-op terms, and the quality of their resulting full-time jobs.  I thought I’d take this opportunity to share what I’ve learned about what co-op jobs you should be looking for at each stage in the Waterloo co-op progression.  This article is the fourth in a series of 6 (parts I, II, III, IV, V, and VI) on what you should be doing for each co-op work term with the University of Waterloo in order to get jobs with the best companies in your last few co-op terms; this part covers your fourth work term.

This series is written for computer engineering students in the University of Waterloo’s cooperative education (co-op) program, which consists of a series of 6 work terms in a repeating 4 months school/4 months work pattern for four years of the student’s five year degree.  Most of the information presented here is not unique to UW students, however; students in a more traditional university program can still apply these tips by ignoring the term specifications and applying them in order to their work opportunities instead.  Longer (8-, 12-, or 16-month) work terms also fit into this model; aim to be done the same things as a 4-month UW co-op student would be at that level of work experience (for example, a 16-month intern should try to complete items up to the 4th work term level by the end of their internship).

Your Fourth Work Term – Being an Asset

Consider returning. The fourth work term is an interesting time for co-op students.  Though the best students are sometimes suited to the top-notch jobs, older students are still competing for jobs and – with their extra terms of experience – tend to shrink the supply of top-notch jobs significantly.  As a result, students looking for their fourth work term positions aren’t often able to get jobs that are materially better than the jobs on their third term – an aspect that is both good and bad.  If you are lagging the rest of your class in the competition for jobs, then the fourth work term gives you the opportunity to even the playing field and play a bit of catch-up.  However, if you are doing well, I would consider returning to your third work term employer; in some cases, you’ll be able to negotiate a better position than you would get going through the interview process.  Why?  You’ve already amassed all of the company knowledge you need in your previous work term, so they can get you started without a ramp-up period.  And they already have four months of proof about how good of an employee you are and how much you can handle – something a new employer won’t have.  Use these facts to your advantage, and discuss with your third work term employer the possibility of returning with expanded responsibilities.  Many employers will be glad to oblige – full time employees are on a similar progressive responsibility ramp, so starting you down that path makes business sense.  My previous advice still stands: even given all of the above, don’t return unless you believe that you’ll be able to pick up more experience.  But at the same time, don’t discount the experience you’ll get from being handed similar projects with more responsibility – responsibility itself is a skill to be learned.  It can be a tough call very dependent on your situation, so do your homework and choose wisely.

Try something different.  If you’ve decided not to return, consider applying to some jobs that are slightly different than what you are used to.  That’s not to say you shouldn’t apply to jobs similar to what you’ve done before (you still should), or apply to jobs you wouldn’t be good at (avoid doing so); rather, think of it as an opportunity to expand your technical abilities.  I’d still strongly suggest taking whatever job that gives you the most experience, but given the competitiveness for jobs in the fourth work term, that level of experience might not be available in the field you are accustomed to.  Being “well rounded” is a desirable trait that is often bandied about, but it doesn’t only apply to one’s non-technical pursuits.  Being well rounded technically is also an asset; real-world technical problems are rarely confined to a single domain.  If you’re a hardware developer, knowing how software developers build software can help you make the best decisions when designing chips, and high level software developers can find a lot of applicable wisdom in the intricacies of low-level system development.  Though these two examples present polar opposite positions, how different that job is from what you are used to is completely up to you.  Even a slight difference gives you a different set of knowledge, and that knowledge may be the thing that gives you an edge over your classmates.   In my own experience, I’ve encountered software developers with the following extra skills that stand out above the rest: computer hardware (saving someone’s dead machine is a great skill to have in crunch times), networks (most software developers have no idea how the internet works), user interfaces (if the user can’t operate your product, then it doesn’t matter if you wrote it in Erlang/Ruby on Rails/Django/some other latest-and-greatest technology), math (the ability to do back-of-the-envelope calculations to determine a solution’s feasibility can save many hours of work), localization (knowing how to write a program that can be used in multiple cultures is a very rare trait – the English-speaking population is only so big), or even sales and marketing (building a program is very different from selling it).  Many developers get by without any of those skills – but most of the best developers I know have some rare knowledge for the field they are in that makes them stand out from the crowd of other good programmers. Taking a job that is slightly outside of the area you’re used to may be the thing you need to develop this knowledge and set yourself apart.

Be responsible for something.  Of all the things I’ve discussed, this is probably the most important.  As much as managers want to believe that they they are hiring an army of employees ready to act on their command, the best employers actually want something more akin to a worker bee: someone who can be tasked with a specific responsibility and given the flexibility to pursue that goal for the benefit of the entire organization.  Co-op students often don’t fit into this model very well; they often need lots of hand-holding and a close watch to ensure they don’t get waylaid.  But by your fourth work term, most employers will be comfortable enough with you to give you some amount of responsibility without watching your every move.  This responsibility is an important step – without being individually on the hook for something, the best employers are likely to pass you by for those that have.  It doesn’t matter what it is, how important it is to the company, or how much money someone stands to lose or gain; what is important is that, when given responsibility, you are able to step up to the plate and knock that responsibility out of the park.  Look for opportunities to be the person responsible for some aspect of the project you are working on, and make sure to do everything you can to make it a success.  Then, keep that aspect in mind when writing your resume (it should be on there) and in interviews (when the interviewer asks for an example, use it).  I’ve known people who, in their later terms, were set in motion at the beginning of the term and then evaluated at the end, without any direct supervision throughout the term.  Those scenarios are where careers are made, when a task is assigned and the some time later assignee comes back with something totally unexpected yet awesome.  The only way you’re going to get one of those assignments is if you can show you can handle smaller amounts of responsibility, so make your fourth work term count in that regard.

Produce measurable results.  Once you get to the fourth-work term level, some of your classmates will start making big contributions to the companies they work for.  They might be at the point where they can lead the team on some aspect of development, or they might be able to deliver a key component, or they might be able to save the company some amount of money – it really doesn’t matter what it is, the result is that they are able to show future employers that they are able to have a measurable effect on the company’s success.  Try to find an aspect of your duties where you can produce a measureable result; often, that aspect is the same thing you were given responsibility for.  You want something you can neatly draw a box around and say “I did that”.  With that experience in hand, you’ll be able to say to future employers that you can help them be successful by doing X, and you’ve already done Y to prove that you can.  This is a continual process, and one that doesn’t stop when co-op does; just because you did Z a couple years ago doesn’t mean you still can, or that Z is even still relevant to the current environment.  It’s the same reason why Steve Jobs is more desirable than Steve Wozniak; both Steves built Apple I and II in the late 70s/early 80s, but Steve Jobs went on to make Pixar a success, save Apple, and build the iMac, iPod, and iPhone.  If you had to make a bet on which Steve would be more likely to make your company successful, which one would it be?  And it’s exactly the same reason you should be trying to produce a series of measureable results – to show potential employers that you have the capacity to do it again, but this time for them.

Posted in Waterloo | Tagged , , , | Comments closed

The Ideal Work Term Progression for Computer Engineers, part III

By Nicholas Armstrong | Published: August 20, 2009

With their Computer Engineering degrees now complete, my classmates (and I, in a sense) are now working at – or searching for – their first permanent full-time jobs.  Looking back on the journey that got us where we are, the one thing that stands out between my classmates is the experience they got while on their co-op terms, and the quality of their resulting full-time jobs.  I thought I’d take this opportunity to share what I’ve learned about what co-op jobs you should be looking for at each stage in the Waterloo co-op progression.  This article is the third in a series of 6 (parts I, II, III, IV, V, and VI) on what you should be doing for each co-op work term with the University of Waterloo in order to get jobs with the best companies in your last few co-op terms; this part covers your third work term.

This series is written for computer engineering students in the University of Waterloo’s cooperative education (co-op) program, which consists of a series of 6 work terms in a repeating 4 months school/4 months work pattern for four years of the student’s five year degree.  Most of the information presented here is not unique to UW students, however; students in a more traditional university program can still apply these tips by ignoring the term specifications and applying them in order to their work opportunities instead.  Longer (8-, 12-, or 16-month) work terms also fit into this model; aim to be done the same things as a 4-month UW co-op student would be at that level of work experience (for example, a 16-month intern should try to complete items up to the 4th work term level by the end of their internship).

Your Third Work Term – Honing Your Skills

Get a job in the industry vertical you want.  Now is the time to really start thinking about the job you want once university is over, and you’ve now got the experience to have a pretty good idea what jobs are available.  Re-evaluate your co-op jobs to see if they are leading you in the right direction, and if not, apply for the jobs that will get you there.  That may mean taking a job that pays a little less, is further away, or is a little easier than you’re used to, but if it gets your foot in the door, it may be worth it.  Even better is a job that combines aspects of your previous job with the jobs you want to get; consulting is a good place to look.  My first two terms gave me some programming experience, but only on small ‘toy’ applications.  By getting a job in consulting during my third term, I was able to turn my slow, inelegant coding abilities into fast, inelegant coding abilities on applications businesses depend on.  My previous experience was an asset to part of my job – developing ‘toy’ applications under tight deadlines for sales purposes – but the other parts of my job increased my capabilities enough to move me into the vertical I wanted to be in for future co-ops.

Learn from everyone around you.  For many people, the third work term is where they really began to feel they are part of the industry.  Jobs that were once assigned to ‘the co-op’ increasingly begin to skip you and land on more junior students’ desks, and the tasks you are assigned are instead the tasks that a full time employee would be doing had you not been available (or had they not been so busy, etc).  Businesses begin to trust you with small parts of real projects that get shipped or shown to customers.  The benefit to this situation is that you get to work with the same tools and products that experienced workers do – so take advantage of the situation!  Suck up as much knowledge as you can from everyone around you, regardless of their seniority or position.  How is maintainable software written?  How do consulting companies get clients to pay on time?  How do you deal with a union?  How do you handle office politics, and who can help you navigate the political issues?  How do you tell which team members are highly valued, and how did they become that way?  There is plenty of wisdom about both the computer industry and the technical skills that it entails wrapped up in the experiences of your co-workers, so make sure to take advantage of them.  You may have been doing this already – if so, great!  In either case, you’ll want to focus on learning from those around for the rest of your work terms – knowing the things they have to teach can make a big difference in the future.

Build a portfolio. The fourth work term is when the very best start to show exactly what it is they are made of, often a result of the nature of the position they manage to land; your third work term needs to prepare you for this competition.  The best co-op positions are ones that provide you with some responsibility, and the best way of getting such a position is to show that you have the skills to handle it.  True responsibility is hard to show on a resume or in an interview, but a useful substitute is demonstrated experience in the area that a potential employer is looking for help in.  To demonstrate your experience, consider building a portfolio that showcases the work you’ve done for past companies, on projects, or for fun.  The goal of such a portfolio is to show potential employers that you’ve done similar things to what they do in the past, and allow them to extrapolate that you would be a much better hire than the student who has no relevant experience.  In particular, you want your portfolio to be specific; instead of the resume-esque “assisted in the development of a sample application”, you want to say “co-developed Project X, where I implemented a cuckoo hashing data store that improved object load performance by 23%.”  As long as the project you worked on isn’t confidential, give the reader a couple paragraphs of insight into what it was, precisely, that you did for your previous employer.  With a portfolio, not only can a potential employer sort the wheat (you) from the chaff (other students who make their coffee-getting skills look like real experience on a resume), but they can also see how you could fit into their team and help solve their problems.  Some (most?) employers may not even look at your portfolios, but even the act of creating one will allow you to reflect on the important parts of your previous work terms, which makes it easy to answer questions about them in interviews.  Finally, as for format, do whatever make sense to you – web site, PDF document, or even a physical binder that you bring with you to interviews.  If possible, do something that is web accessible, since it’s easy for employers to access, and they can have a look when reviewing resumes.

Don’t forget interview skills.  Your third work term isn’t just about honing your technical and business skills – interview skills are also important to work on.  If you have the opportunity, attend the interviews your employer does to find the co-op student to follow you.  Try to identify the aspects of each candidate that suit them to your job, and what it was that made you decide that they were (or were not) suited.  It’s very likely that you will field similar questions in the future, so pay attention to what style of answer best conveys the candidate’s qualifications (no joke: I sat in on an interview where the candidate literally read the answers to our questions off a sheet he had prepared and brought in with him.  Two things I learned: prepared answers read or memorized word-for-word sound too mechanical and formal in an interview context, and you have to learn to think on your feet – the candidate crashed and burned as soon as we asked him a question not on his prepared sheet).  Even when you’re the one being interviewed, try to figure out the protocol for the interview – who is the technical interviewer and who does the HR questions; how you can help them solve their problems; how your experience meshes well with their business; whether stories or detailed technical answers work better; how much technical detail is expected; how the employer will take it if you disagree with their opinion (which can be the thing that gets you the job offer; some interviewers push until you push back).  Taking an active approach to the interview process will serve you very well, as many students have trouble with the interview portion of the co-op process – by offering you an interview, the employer has already recognized that they could see hiring you; the job is yours to lose.  Take advantage of the time you spend in an interview, on either side of the table, to develop your knowledge for future interviews.

Posted in Waterloo | Tagged , , , | Comments closed

The Ideal Work Term Progression for Computer Engineers, part II

By Nicholas Armstrong | Published: August 17, 2009

With their Computer Engineering degrees now complete, my classmates (and I, in a sense) are now working at – or searching for – their first permanent full-time jobs.  Looking back on the journey that got us where we are, the one thing that stands out between my classmates is the experience they got while on their co-op terms, and the quality of their resulting full-time jobs.  I thought I’d take this opportunity to share what I’ve learned about what co-op jobs you should be looking for at each stage in the Waterloo co-op progression.  This article is the second in a series of 6 (parts I, II, III, IV, V, and VI) on what you should be doing for each co-op work term with the University of Waterloo in order to get jobs with the best companies in your last few co-op terms; this part covers your second work term.

This series is written for computer engineering students in the University of Waterloo’s cooperative education (co-op) program, which consists of a series of 6 work terms in a repeating 4 months school/4 months work pattern for four years of the student’s five year degree.  Most of the information presented here is not unique to UW students, however; students in a more traditional university program can still apply these tips by ignoring the term specifications and applying them in order to their work opportunities instead.  Longer (8-, 12-, or 16-month) work terms also fit into this model; aim to be done the same things as a 4-month UW co-op student would be at that level of work experience (for example, a 16-month intern should try to complete items up to the 4th work term level by the end of their internship).

Your Second Work Term – Being Different

Plant seeds for future terms.  Now that you’ve gained some experience, it’s time to put in motion the things that will get you to the top.  As long as you make the right job choices, work terms are cumulative, so getting a job that is just slightly better than your classmates your second term will allow you to get jobs that are that much better again in your third term, and the cycle repeats until you’re one of the few getting offers for top-of-the-line jobs.  The key is to start doing some things that will pay off in the future – start volunteering, for instance (there are plenty of places on campus – getting an EngSoc directorship both improves your university experience and looks good on a resume, and is usually a lot of fun).  Another thing you should start doing is sending a few applications to the top companies you want to work for, even if you don’t have the skills yet.  Many of the recruiters follow student progress, so submitting an application starting in your second or third term may give you an edge in your later terms (don’t go overboard, though).

Avoid going back. Unless you’re one of the lucky few that finds a job they absolutely adore in their first term, going back isn’t the best strategy.  Now that you’ve got some experience, the majority of your job options will be better than your first work term position.  Remember that you’re competing against your classmates for the available jobs; while some will come from behind to get great jobs in the end, it’s a much better strategy to try for a better position every term (the tortoise strategy in the tortoise and the hare) .  That’s not to say you can’t go back to the same company – or even the same position – but make sure when you do so that you expect to get the same amount of experience as you would had you applied elsewhere (NB: if you haven’t noticed, it’s all about experience.  Switching jobs may result in a pay cut, but should resolve itself in the later co-op terms.  I took a 15% pay cut in my second term for a job that provided better experience, but as a result I was making almost double my first term salary by my fifth term).  Just because it’s easy to stay where you are doesn’t mean you should do it – I’ve known a number of people who got laid-back jobs in their first term and stayed on for a second; not only did they regret the second (as four months of the same boring deal), most had trouble getting good jobs in future terms, too.

Stand out from the crowd.  Employers comb through hundreds of resumes, each one a variation on the same theme.  Your goal is to stand out – in a good way! – so that they remember you when it comes time to pick candidates to interview, and when it comes time to choose who to offer a job to.  What does that mean?  Spend time making your resume perfect; spelling errors make you stand out, but the way you are looking for.  Do your homework before going to the interview, so that you’re able to discuss the company without making wild guesses (don’t try to lecture the interviewer on how much you know, though).  Have that one piece of experience that everybody else doesn’t have, be it technical or volunteer.  When preparing your resume, consider mentioning something unusual about yourself (may be you play an odd musical instrument – the bodhrán, perhaps – or have an unusual hobby; anything harmless but odd is perfect).  Don’t force it, but you’ll occasionally get a comment out of the blue about whatever you mentioned that cements you in the interviewer’s mind.  Knowing technical detail unexpected of a co-op student can also help you stand out – I shocked an interviewer once by knowing how garbage collection in .NET worked, and diffused another one by observing that his interview question was equivalent to the knapsack problem, which is NP-complete; both interviews led to job offers.

Aim for the industry vertical you want.  This is the term to start positioning yourself for the jobs you want in your later co-op terms.  If you’re looking for hardware jobs, bias your applications toward hardware positions, and the same goes for software or IT positions.  At this point, you just want to make sure you’re in the right general area; you don’t need to have all of the factors (like application type (web, desktop) or programming language) perfect yet – that’s for future terms.  If you started in the right vertical, great; if not, getting into the vertical is a lot easier on your second term than any other term.  Most of the people I know have done the same style of jobs since their first or second term, as you need the right set of circumstances to make a change without ignoring some of your experience (I cover the best way of switching during the third work term).

Follow your stats.  This is not strictly necessary, but I’d highly recommend it – start keeping track of the number of jobs you apply to, the number of interviews you get, and the number of offers you get from those interviews.  When you’re just starting out, expect those numbers to be low – but that’s OK. Whenever you get an application rejected or a job ranked or not-ranked instead of offered, review the job posting or your interview performance in order to figure out why it didn’t work out.  Were you applying for a job that you had little chance of getting?  Did you respond poorly to a question?  Were you up against a classmate who writes compilers for fun?  Figuring out why things went the way they did is the secret to making your stats go up, as you’ll know how to handle similar situations in the future.  And having good stats is a blessing: you’ll either have to attend less interviews (less stressful) for the same number of job offers, or get more job offers and have more selection (at the cost of more time spent interviewing).  By my fifth term, I turned 14 applications into 9 interviews and 8 offers – an 88% conversion rate from interview to offer!  That same term, I knew people who did 20-30 interviews and 40-50 applications in order to land a single position; not only did they work harder, but they had less selection, too.

Posted in Waterloo | Tagged , , , | Comments closed

The Ideal Work Term Progression for Computer Engineers, part I

By Nicholas Armstrong | Published: August 14, 2009

With their Computer Engineering degrees now complete, my classmates (and I, in a sense) are now working at – or searching for – their first permanent full-time jobs.  Looking back on the journey that got us where we are, the one thing that stands out between my classmates is the experience they got while on their co-op terms, and the quality of their resulting full-time jobs.  I thought I’d take this opportunity to share what I’ve learned about what co-op jobs you should be looking for at each stage in the Waterloo co-op progression.  This article is the first in a series of 6 (parts I, II, III, IV, V, and VI) on what you should be doing for each co-op work term with the University of Waterloo in order to get jobs with the best companies in your last few co-op terms; this part covers your first work term.

This series is written for computer engineering students in the University of Waterloo’s cooperative education (co-op) program, which consists of a series of 6 work terms in a repeating 4 months school/4 months work pattern for four years of the student’s five year degree.  Most of the information presented here is not unique to UW students, however; students in a more traditional university program can still apply these tips by ignoring the term specifications and applying them in order to their work opportunities instead.  Longer (8-, 12-, or 16-month) work terms also fit into this model; aim to be done the same things as a 4-month UW co-op student would be at that level of work experience (for example, a 16-month intern should try to complete items up to the 4th work term level by the end of their internship).

Your First Work Term – Getting a Job

Make an effort. Students first applying for jobs after 2 weeks (4-stream) or 4 months and 2 weeks (8-stream) of university.  As a result, 4 streamers only have their high school experience to go on, and 8 streamers have the same one programming course and handful of science/math courses that their classmates do.  In either case, experience is lacking, and one co-op student looks pretty much like the next to an employer.  What do you do?  Make an effort when writing your resume and cover letters, and when preparing for an interview.  That means getting your resume critiqued, and acting on the feedback you receive.  It means spending time preparing for interviews, practicing with friends, and researching the companies you are interviewing with (and who they sent out to interview you, if possible).  And it means writing cover letters for the jobs you are most qualified for (or want the most), and writing personalized cover letters from scratch for each company – form cover letters just don’t cut it.  With all of the things that go on during the beginning of a term, it’s easy to let these things slide – but in your first term, it’s to your peril.  Not getting a job can not only set you back financially, but also makes finding jobs in the future that much more difficult.  By making an effort, you’ll set yourself apart – even if only by a little bit – from your classmates.  And in first year, that extra effort may be the difference between getting a job and not.

Apply, Apply, Apply. Every hiring manager is different, and looks for different things in a co-op student: experience, grades, extra-curricular activities, hobbies, hometown, you name it.  Without the one thing that carries other co-op students – experience – first year students get hired on everything else.  And since you cannot determine beforehand what it is a manger is looking for, the only rational solution is to play the odds and apply to a large quantity of jobs.  You’ll want to make the most of your application limit – don’t throw away applications on positions you have no chance at getting (primarily, those marked ‘Senior’), and positions with fewer applications are more likely to grant you an interview – but make sure you use every application you have.  You can be picky about which jobs you take after you’ve been offered them – but that means you need to both get an interview (only a small percentage of your applications will turn into interviews) as well as be the best candidate (your odds are better, since you’ll only be fighting a handful of students for each position, but it’s far from certain).  One exception to this rule: never apply to a job you don’t ever want to do.  You’ll always have some jobs that are better than other jobs, and that’s OK; on ranking day, you can make the selections that get you the best job from the ones you are offered.  But applying for a job you wouldn’t want to have is never a good strategy; if they’re the only company to offer you a job, then you could very well end up with it, and spend four months in agony.  You’ve been warned.  The basic principle remains, though: more applications = more interviews = more job offers, and the only one of those you can control directly is the number of applications (making an effort improves the conversion rate between applications/interviews/offers).

Get any job you can. Actually, this should read ‘get any job you can that you enjoy doing’.  In all likelihood, you’re not going to be able to pick your job area with any precision; in my first term, I applied for IT, software, and hardware jobs, and only got interviews in IT and software – and some of my classmates only got interviews in IT after applying to all 3.  Unless you’ve got prior experience in an area (with a particular programming language, software tool, etc.), limiting yourself to narrowly focused fields (.NET, Java, Ruby, etc. development) will probably not result in enough positions to fill your application count.  And even if it does, you could be competing with older students that do have experience in one of these areas, so applying exclusively to a single field is a pretty big risk (think of the ‘eggs in one basket’ metaphor).  It’s impossible to know what a company is looking for and what other students have applied, so a diverse application strategy is most likely to pay off.

Identify your dream job’s field/industry vertical.  There are many potential career pathways leading from a degree in Computer Engineering (and other similar programs, like Software Engineering and Computer Science) – a short list is hardware/software development (and their many subdivisions, including in-house and contracted development), IT work, and other jobs related to technology (tech policy/tech law, etc.).  The general rule is that the best jobs in those fields are found when the majority of your co-op experience culminates in that job.  So with a lot of hardware development experience, your chances of working for Microsoft/Adobe/Amazon are limited, but are quite a bit better for positions at NVIDIA/AMD/Intel; the reverse holds if you have a lot of software experience.  If you know where you want to be in the end, then try to accept jobs that put you in the right field.  Without experience, some of these fields are hard to get into in your first term, and getting a job is paramount – don’t focus your applications on a specific vertical yet; you can do that in future terms.  But if you’ve been offered a few different positions, consider leaning toward the jobs in the field you want to be in.  Don’t worry if you don’t have and idea where you want to end up yet – most people develop that as they work their way through and get more exposed to the industry, and you can change your goal as you progress.

If all else fails, improve your skills. Sometime, your best efforts aren’t enough to get you a job.  Here’s the secret: it’s not going to get any easier the next time through – your classmates will have experience you don’t have, which puts you in worse shape than you were in in the first place.  Even if you don’t have a job, gaining experience is your number one priority.  Learn a programming language – something used in industry (C#, Java, C/C++ are best, but Python or Ruby will do) – well enough to build a useful program (‘Hello, World’ doesn’t count).  Contribute to an open source project – write documentation or find bugs if you cannot code.  Set up a network of computers and do something with them – run a DNS server, configure a web farm, do distributed compiles.  Take classes at your local college.  Start a business.  Fix up your resume, and practice interviewing.  Anything is better than sitting around doing nothing for a term, but relevant experience is what you’re really looking for.  Just because it’s not for pay doesn’t make it any less useful on a resume – and you can potentially do better than some of your colleagues who chose co-op jobs unwisely.

Posted in Waterloo | Tagged , , , | Comments closed

XAML: Not Just for UI (part II)

By Nicholas Armstrong | Published: July 20, 2009

Continuing from part I in the series, this post describes some of the tricky bits for implementing your own XAML-based test data loading infrastructure.

For those that haven’t read part I, the story to this point is that XAML can be used to do some things that are completely unrelated to user interfaces – like loading test data – and that some of the benefits that XAML provides to WPF it also provides in other scenarios as well.  I’d suggest heading on over and giving it a quick scan if you haven’t done so yet.

The Situation

The sample presented here was derived from my fourth year design project, a WPF-based interface to ‘smart’ home devices.  The simplified environment presented here contains Locations (rooms in a house), and Devices (things you can manipulate, like lights and radios).  Devices have Attributes, which are individual features of the Device that can be controlled (e.g. each of a lamp’s two light bulbs is mapped to a separate attribute).  In the actual project, each Attribute (there were multiple types) had its own DataTemplate defined, so that when an Attribute was displayed on screen the accompanying control was displayed so that users could change the value of the attribute (turn the light bulb on or off).

To test all of this, we needed a way to load many locations and many devices containing many attributes.  And we needed multiple sets – or ‘houses’ – of test data so that we could ensure that everything was working properly, that all of the types of attributes were displayed, etc.  To load all of this data, I put together a test data loader that loads a set of locations, devices, and attributes from a XAML file.

The rest of this article describes some of the tricks you’ll need to know in order to get this working for your projects.

The Tricks

ContentProperty Attribute

Though not strictly necessary, putting a ContentProperty attribute on your classes will allow you – and the XAML writer – to be less verbose when writing your test data XAML.

For instance, on our Device class, we have the attribute

[ContentProperty("Attributes")]

So that the corresponding XAML goes from

<Device Name="Lamp" LocationId="4">
    <Device.Attributes>
        <Attribute Name="Bulb" Power="150W"/>
        <Attribute Name="Bulb" Power="60W" Position="2"/>
    </Device.Attributes>
</Device>

to

<Device Name="Lamp" LocationId="4">
    <Attribute Name="Bulb" Power="150W"/>
    <Attribute Name="Bulb" Power="60W" Position="2"/>
</Device>

Basically, the ContentProperty attribute sets some property of your class as the ‘default’ one as far as XAML is concerned; that way, anything you put inside the class’ definition in XAML without specifying which property it belongs to will have it generated into the property specified by this attribute.  If I had to hazard a guess, I’d say that the name ‘content property’ was used instead of ‘default property’ since it’s the content of an XML element you’re talking about, and XAML is based on XML.  Alternatively, it might have picked up the name from WPF, where controls like ContentPresenter, Button, StackPanel, etc. all have properties actually named ‘Content’… and the ContentProperty attribute is used to set these ‘Content’ properties as the ‘Content’ property for each of their respective classes.

No Generics support before .NET 4

Loading in test data is usually a straightforward affair: create a list to hold the data we’re expecting, then load it into that list.  And in C#, the easiest way of declaring such a list is to use generics:

List<Device> devices = new List<Device>();

Unfortunately, XAML prior to .NET 4 does not support generics, so writing the above code won’t serialize that property.  It’s relatively simply to fix, however: we just have to trick XAML into thinking that our List<Device> class is a real class by inheriting from the generic class:

public class DeviceList : List <Device> { }

And then we can use the DeviceList class in place of List<Device> in our original code, with the benefits of not having to re-implement List as well as being a non-generic class so that it can be saved to XAML.

The classes involved have to be public

There are a number of limitations as to what sort of classes and properties can be written as XAML (since the XAML loader needs to be able to create objects for all of the items in a XAML file), one of which is that the properties and classes that are being written to XAML need to be public.  There are a number of other limitations as well (Mike Hillberg has a good post on the subject), but this limitation is likely the only one you’ll encounter when you’re using XAML for test data loading.

Saving an existing data model

Typing out all of your data, even with Intellisense’s help, is a thankless task.  Luckily, there’s a simple way of having the XAML infrastructure do it for you.  Simply copy the data structures of interest into your test loader class’ definition, and then, in one fell swoop, write everything out to a XAML file:

using (XmlTextWriter writer = new XmlTextWriter(location, Encoding.UTF8))
{
    XamlWriter.Save(this, writer);
}

Perhaps an even better way of doing this is to wrap it all up into a Command on your main window, bound to a keyboard shortcut.  Then whenever you encounter an interesting scenario or some buggy behaviour, you can just hit the shortcut (in the sample, it’s Ctrl-D) and have test data for that case generated automatically!

DesignerSerializationVisibility Attribute

By default, XamlWriter only writes out values for the public, read-write properties of a class.  The reasoning behind this is straightforward: if the XAML loading infrastructure cannot load the data value back in (which it cannot for private and read-only properties), then there isn’t any point in writing those properties in the first place.  There is an exception for collections: the XAML loader can load values into a collection exposed by a read-only property by using its Add() method, so these properties can (and probably should be) be read-only.  The default behaviour of not writing these properties out still applies, however, so you’ll have to give the XAML writer a hint for it to save these properties.

That hint is the DesignerSerializationVisibility attribute, which, when set to ‘Content’, indicates that the XAML generator should produce XAML for the contents of the object – precisely what we’re looking for.  So we tack the following definition on our read-only collections in TestDataLoader (Locations and Devices):

[DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]

and everything works as we were expecting, with all of our read-only collection properties saved to XAML.

Using Intellisense on your test data XAML files

One of the neat things about this approach is that you’ll be able to use Intellisense when editing your test data files in Visual Studio.  Just as if you were editing a WPF XAML file, it will prompt with the right elements at the right spots, auto-complete tags, and list out all of the values for any enumerations you use!

To get this to work, you’ll need to add the XAML file to your current project (Visual Studio doesn’t provide Intellisense for files that aren’t part of the current project).  Then, change the build type for the file from ‘Page’ to ‘None’; otherwise, it will try to compile the test data XAML into your application as code generated classes.  And that’s it – as long as your namespaces are declared correctly in the XAML test files (and they will be if you exported it from the application in the first place), you should see full Intellisense support!

The Code

Now that I’ve discussed the tricks you need to do it on your own, it’s time to share some source code so that you can have a look at an end-to-end example.  Grab the source, then try loading some of the sample data files into the application.  Or mock up some data by using the add buttons to add locations and devices, and then watch what happens as the data model is saved out to XAML.  Enjoy!

Posted in WPF | Tagged , , , | Comments closed