We at tretton37 never do anything half arsed. We’re into SharePoint and we mean it. We are ninjas, even on SharePoint!

I firmly believe that SharePoint is truly ninja. What other system is awesome for collaboration straight out of the box, useful as a content management tool, has document versioning and workflows, can calculate large spreadsheets, batch convert documents, or integrate with obscure backend systems? SharePoint can do all of that and much more.

SharePoint can exist on its own servers, be it real ones or virtual but it can also exist at Microsoft Data centers; courtesy of SharePoint Online.
SharePoint has evolved over the course of more than ten years. Many of the core concepts that where there from the beginning are still there. Some of the refinements in the latest installment are an enhanced enterprise search (especially with FAST), a rather impressive “My Site”, and a very useful taxonomy (tagging) system.

SharePoint is also a large and extensive development platform. It can solve business problems, and a rather full range of business problems at that.

However, there are some dark clouds in the otherwise blue skies of SharePoint. It does not excel as a content management platform for public-facing internet sites without some deep thinking and special implementation details. It is not very mobile or tablet friendly out of the box, although some of the recent cumulative updates have addressed some of the problems, among other things.

So, where is the ninja stuff?

SharePoint as a development platform is huge. The foundation is .NET Framework 3.5, which might not be the latest and greatest but does the job. There’s Business Connectivity Services (BCS) to connect to any other system imaginable, either using WCF services or custom code – giving great integration possibilities. With the Client Script Object Model (CSOM) and custom tools like SPServices, one can build really nice, productive and fluid user interfaces on top of SharePoint.

As with any platform one needs to work with the grain of the fabric when developing SharePoint. What’s different from other web technologies or frameworks like ASP.NET MVC is the sheer size of the fabric we have to work with and the rather steep learning curve. Building properly on top of SharePoint requires a very good understanding of how the platform works and what parts to use for what purpose, and believe me; there are many parts. Beyond that developer tooling may sometimes be tedious at best. For instance one needs a full server installation just for development, which makes development start-up time for new projects significantly longer than with other web technologies.

The ninja part comes with deep experience in developing for SharePoint, choosing the right approach for the problem, applying standard features or custom development. A problem can often be solved in one of many different ways, it takes a ninja to know the right one.
And this is just for developing solutions. There’s room for much more under the SharePoint flag; Configuration management, Infrastructure, Integration, Security and more.

On the topic of SharePoint and ninja or not, I think the following piece by Mark Rackley is explaining it rather well, especially the twitter quote:

“@mrackley: Here’s an interesting question. Is it possible to be a “Junior Architect” in SharePoint? I think by its nature it’s a senior position.”

“@cmcnulty2000: I once met a junior surgeon. Didnt use him though. (my favorite response)”

There are so many facets of SharePoint solutions and development that a single person can’t really know it all (except some people – but a select few have cleared that certification).

Want to know more? Send me an e-mail or leave a comment

I’m sure you’re familiar with this situation, and if not, you’re either lucky or new: Starting a new assignment and taking over someone’s code, code that is in some sort of state of decay or disarray. Bonus points if the original author isn’t even around anymore to answer any questions you have. Extra bonus points if there’s no source control.

I’ve done this scenario quite a few times now, and the experience for me has gone from horror and bewilderment the first time I did it, to actually now enjoying it. As long as you have a proper and well thought through approach, I’m positive you can turn almost all code around.

What about rewrites then? It’s almost a mantra that if code is old enough it should have been rewritten. I’m sure there are times when this is the right choice, but it carries a very high risk. Going through code you sometimes find really odd pieces, which seems to do elaborate things for obscure reasons. Those, ugly as they may be, are sometimes gems of knowledge on how to handle specific corner cases. If you rewrite things, you will lose those gems. Another huge risk is the time when rewriting and you still have to manage the old system in addition to rewriting it. With features actually going in to the old stuff while writing new, and the split focus; you’re threading on perilous ground. Ask the Netscape guys, they should know.

So, refactoring is, in my opinion, the way to go in most cases. I’m going for the old-school definition of refactoring here – changing the implementation without altering the functionality. Don’t try to improve on what the thing actually does when you refactor. Just make it pretty on the inside. My approach to this is almost formulaic by now:

First off the bat, write tests for the existing code base – try not to change the code base too much. If any refactoring is to be done, it should be in order to increase testability. Aim for a coverage percentage you feel comfortable with, but don’t aim too high. As long as the coverage percentage doesn’t become a goal in itself – there’s quite a few horror stories about what has been done to increase code coverage. I remember hearing once about a guy who wrote a function that just iterated through every available function, calling it with null or 0 and ignoring the result and catching all exceptions. That sort of test is even worse than no tests whatsoever, since this leads to false security. Refactor the unit tests as well. I sometimes wonder why test code doesn’t get the same refactoring love that “normal” code does. It deserves it, test code is the only code that will find bugs instead of causing them.

Then refactor. The important thing is to not try to force the code into something it was never intended to be, say moving a webforms app to a MVC app while refactoring. That’s in the realm of rewriting, not refactoring. Instead, make it the best webform app you can. The point is to step-by-step make the codebase smaller, and thus more malleable. I usually find it easiest to work from the bottom up, starting with the data layer and ending up in the UI. As long as the refactoring never takes the form of scrapping an entire module of code, you should be able to continually have a working product throughout the process.

Use a good tool! I like ReSharper. Consider style warnings for your tool of choice as errors and accept no deviations. Spending time adding features like a keyhole surgeon to an uncontrolled codebase is producing waste and, more importantly, consolidating broken code.

That is just my two cents…

During Øredev this year we decided to have a zeppelin in our booth, and to make it more fun we decided that it should be remote controlled! After a few iterations (hardware projects can be done agile too) we ended up with the following thing – an Arduino powered zeppelin that communicates with a computer using XBee and is controlled with a Wiimote connected to the same computer. The leetZeppelin was built by Fredrik Leijon (@fleijon) and Marcus Olsson (@_macke_). We think that all the gazing at the sky and half opened mouths proves that it was a huge success!

We started with a remote controlled Blimp from rctoys.com and as soon as it arrived we gutted the gondola to make place for the Arduino controller we wanted to use.

First version

However, after some testing we realized it was too heavy and hard to steer so we decided to build our own gondola and ended up only using the engines that came with the Blimp kit.

The second version of the gondola had two motors that were able to change angle of the motors to direct thrust and easier steer the zeppelin. The motor mounts consist of carbon fiber tube glued to a Lego rod with a gear connected to a servo motor. Servo and the motor mount where glued to a frame of cardboard.

Servo controlling motor direction

Motor mount

To be able to drive the motors in both directions (to be able to go both forward and reverse) we dismantled 2 servos and jury rigged the controllers to work as motor controllers.

Fredrik modding a servo motor

Modded servo control

The zeppelin is controlled by an Arduino FIO. We chose the FIO since it has a connection for LiPo batteries and a XBee module can be mounted directly on it. To create place for the battery we used some Lego bricks for creating space between the Arduino and the cardboard frame. The Lego was glued to the frame and we used tape to attach the micro controller.

Finished gondola

Just for the lulz we added an IR Led and the code for TV-B-Gone that allowed us to turn off TVs if a secret key combination was pressed on the Wiimote. We used a slightly modified version of Ken Shirriff’s Arduino port of the tv-b-gone software.

Tv-B-Gone IR Led

The computer controlling the zeppelin has a Wiimote and an XBee module, the software used to control the zeppelin is written in python using wxPython. The purpose for it is to parse input from the Wiimote and send it to the zeppelin.

The computer communicates with the Arduino controller over a serial port; the XBee modules create a wireless serial link between them. To get input from the Wiimote we used the CWiid library with a python wrapper. The reason for using python and Linux was simply that it allowed us to quickly build a working solution and the Wiimote library’s for Linux works a lot better than Windows versions.

Here’s a list of the important parts used.

Hardware - Zeppelin

• Arduino FIO
• XBee
• Servo motors
• 2 x  Servo motor or motor controller
• Motor
• Proppeler
• Blimp Balloon Envelope (rctoys.com)
• IR Led
• Carbon fiber tube
• Lego Gears
• Lipo Battery – 1s 1000 mAh

Hardware - C&C

• XBee
• XBee Explorer USB
• Wii mote
• Computer running Linux
• Bluetooth dongle

Software

https://github.com/evilmachina/leetZeppelin

Some of the pilots

Happy pilot

Preflight check OK

How can you introduce a new co-worker the first day at work, so that he or she will feel welcome and become a committed team member as soon as possible?

With recent experience from two well working start-ups, last month I’ve been thinking about what I appreciate during the first week. Things like trust, being dedicated and having fun are important to keep me healthy and happy, both at work and as a person in general. I think Antonovsky‘s three parts in “Sense of coherence” sums up my feelings pretty well:

- Comprehensibility: a belief that things happen in an orderly and predictable fashion and a sense that you can understand events in your life and reasonably predict what will happen in the future.

- Manageability: a belief that you have the skills or ability, the support, the help, or the resources necessary to take care of things, and that things are manageable and within your control.

- Meaningfulness: a belief that things in life are interesting and a source of satisfaction, that things are really worth it and that there is good reason or purpose to care about what happens.

The purpose of this post is not indented to act as guide for the perfect computer setup or routines for the co-workers. This is rather some thoughts and ideas on how to turn a new co-worker into a confident, independent part of the team with a “sense of coherence” and perhaps a friend for life.

The perfect workstation?

Preparations

Make sure that you are prepared for taking care of the new colleague before he or she arrives. There is some stuff that might take some time to fix. It might be necessary to order things – like a new computer, cell phone, a chair or a desk. Except from the hardware, verify that all needed software licenses are ordered beforehand. Make sure that the colleague will have access to all support systems that’s not under control by the team e.g. login to the AD, management systems for time reporting and salary. It’s also important that the colleague has access to the building.

Things that are controlled by the team and easy to fix are not that important, since the new colleague will become part of the team. The key is to get rid of all impediments that takes time to fix and are not controlled by the team.

Introduction to the company
A well-presented introduction that explains the vision and core values of the company acts as a foundation for the rest of the career and will make it easier for the new colleague to strive against the same goals as the rest of the organization. Give the new colleague a short introduction to the different divisions of the company, to make him or her feel safe, independent and aware of where to turn if problems occur.

Integration with the team
Make sure that another team member team-up with the new colleague during the first stand-up meeting. They should start on a new task with low complexity together. This is a brilliant opportunity for exploring the code base, interesting design choices, code standards, how we write tests, etc.

During this phase, take care of all necessary setup needed for a developer that’s within control of the team. This could be things like access control to the versioning control, issue tracking, continuous integration server and DB. This will add transparency, and give a good overview for the new colleague of what’s needed to get up and running.

Making a push
Work together on the task and make sure that you’re making a push to a new feature branch.

I don’t think that the preparations above will cause any overhead for the company, but rather a nice way to say to welcome.

Don’t forget about soft rules and fun stuff, like routines for lunch dates and after work arrangements.

How do you think the first day should be organized for a new co-worker?

Recently I was struggling with how to share and re-use code between my current client projects. An easy copy-paste of the code wasn’t an option, off course, since I don’t want any duplicated code. I could probably create a separate solution with the code I want shared and branch that code from our source control to the projects that need the code. As soon as I thought of this option I saw problems with people forgetting to merge back any changes in the shared code.

Pretty soon it came clear to me that I just wanted to share the binaries. A simple solution would be to copy-paste my binaries. But since it does happen that we make changes to the shared code it would be easier with some kind of infrastructure that supports updates. The answer to my problem is called NuGet!

NuGet is an extension for Visual Studio 2010 that makes it a joy to install and update third-party libraries, and this can also be used for internal libraries. More about NuGet and how to use it can be found on NuGet.

To show you how I implemented this, I will use a simple project that contains an INinja interface and a .nuspec-file. The .nuspec-file specifies how the NuGet package should be generated (more about package generation in the NuGet Docs).

In order to generate a NuGet package you need to download the NuGet Command Line from Codeplex (the file is included in the code sample).

In the root folder of the solution I have added a bat-file with the following content:

What this does, basically, is that it starts with building the package with my project file as the source. The xcopy command copies the generated .nupkg-file to my file share (in this case it’s the Packages folder, but could of course be a network file share and there is also a NuGet server available as a NuGet package). The del command cleans up the created files in the local folder.

To be able to take advantage of your new awesome NuGet package you only have to go to the NuGet settings in Visual Studio and add a new package source with the path to your share (in this case the Packages folder).

If you update the source code in your package, all you have to do is to update the version number in the projects assembly information and rebuild and publish the NuGet package. Then there will be a new version of the library for all the consumers to upgrade to.

If you are making daily changes in the shared code then probably this isn’t the best and most efficient solution, but it seems to be working good when it isn’t updated that frequently. The greatest part of it, is that you can say “Hey, there’s a NuGet for that!” when someone in your team wants to copy your awesome code ;)

Please feel free to check out the code sample on GitHub and drop a comment or suggest any improvements below. I’m already planning on letting our CI environment take care of both the generation and publishing of our packages.