Nu är min och Karl-Henrik Nilssons session, “Bygg en bättre morgondag med Windows 10, Raspberry PI och Microsoft Azure” från TechDays 2015 tillgänglig på Channel9!
Nu är min och Karl-Henrik Nilssons session, “Bygg en bättre morgondag med Windows 10, Raspberry PI och Microsoft Azure” från TechDays 2015 tillgänglig på Channel9!
Wearables is a hot topic and something that I am very interested in.I think that 2015 is the year when wearables are blooming. I just wrote a blog post about it for Sogeti Labs. You can read the whole blog post here;
The year of the wearables on Sogeti Labs
When I started out with Episerver I quickly ran into problems. As a consultant I travel a lot and my companys VPN-solution is far from good so I always work “offline” from my company when I burn late nights at the hotel.
The first site I set up on my machine got a yellow screen of death when I tried to log into Episerver with the CMSUser account. I got an error saying “The trust relationship between this workstation and the primary domain failed”. Not a verry good start on the first project and I didn’t find any good reasons why.
If you find yourself in a position where you get the same error, the reason and solution is quite simple. The reason that the error appear is that the account I tried to log in with was a domain account and when the login attempt happened an attempt was made to verify the identity against the AD. Since I didn’t use VPN that was impossible.
So how can you fix this? The best way is to add a local account on your computer and use that for the login against Episerver. Make sure that the account you add belongs to the Administrator group on your machine. Doing this will allow you to run Episerver on your local machine anywhere you are.
Recently I visited TechX Sweden, a new IT-conference described as summarizing the best from Build and Tech Ed. I was disappointed to say the least, if this was the best they can cancel both Build and Tech Ed. Since I have visited Tech Ed I know that it is far better than this! =)
Anyway, it was not only the content that was below an accepted level but the presenters! The presenters are pros and gives talks all the time so they should know how to avoid the biggest no no’s when giving a talk or presentation. I have summarized my top 5 no no’s below. Follow them and you will become a better presenter in no time!
When giving a talk, the room is filled with people that are there to listen to what you have to say. You know your material and what is shown on the projector, so STOP turning around facing the presentation on the wall when you talk. This is a so common thing among unexperienced (and experienced that don’t work their presenting-skill) that when they change their PowerPoint slide, they turn around and speak into the wall explaining the static image. You should know your material good enough to be able to face the audience and speak to them! If you are nervous, be sure to have your presentation computer in front of where you are standing, that way you can take a quick look at the screen to see that everything is working behind you. This will give a more inviting touch to your presentation style and you will be perceived as more professional. A note here, watch out so you don’t end up looking into the computer screen instead, focus on the crowd!
If you are planning on giving demos, make sure that they work! It is not OK to have planned a demo that will show of cool features and when it’s not working try to explain what cool thing that should have happed if it worked. This will only make you look foolish and unprofessional. Sure bad things can happen. You might rely on an internet connection and it goes down before your talk. It’s up to you to have a fall back strategy for when the environment is not optimal. If the internet connection goes down you should have an offline version instead. To cite Queen; “The show must go on”! Work on your demos, try them out a couple of times before you enter the stage and be prepared! And oh, when trying them out, it is not OK to put demos in a state that when you run it the next time it will be a different experience and you figure that you will cover it up by explanation, DON’T! Reset the demo. E.g. if you are demoing a web site that will use Google log in, it is not OK to skip that part of the demo because you are logged in from test running the app and explaining “well this would happen but it didn’t…”.
When planning your talk, be sure that there is a red thread that goes through your talk and be sure that it will reflect your title. E.g. if you are about to give a talk about news in ASP.NET MVC 5, don’t ramble on about how much better Web API are at things or how you have created hacks to override things in the framework. Give the talk about news in MVC 5 and focus on that! If you don’t have a red thread for people to follow they will be confused. “What is he trying to say? What is his message? Ah fuck it, who wants ice-cream?”. Work your material and be sure to stay on target!
When giving a talk where you have your PC/Mac etc. connected to a projector, be sure to have your machine in a mode that is presentation-safe. With this I mean that what happens on your screen will be shown to the crowd. This means that you don’t want distractions from what you are presenting. Example, be sure to clean your browser history so if you are using your browser for a demo, you will be sure that the audience is not distracted by your browser history containing entries of Piratebay, IloveCuteCats.com or StarTrekRealRolePlayes.com. Clean it up and let the audience focus on the presentation / demo itself.
Also turn of all other distractions like email notifications. They can be containing private information about your company or clients, or they can be of private nature. It is not ok if any of this appears on the screen. This is very unprofessional!
Keep your computer in a state that is ok for public display. This can be done either by just closing all apps or you can set up a separate user account on your machine just for this purpose. It’s up to you to find a solution that works for you, the importance is that you do it.
The most common pit fall when giving a talk is that you haven’t practiced enough. Be sure that you know your material like you know the inside of your own pocket. Only then can you be confident enough to really rock the stage. When you know the material it is important that you practice your performance. Practice your talk over and over. If you have the option, tape the practice and watch yourself to find weird things that you do. For instance, do you waive your arms around all the time, or do keep saying “Eh” all the time? Find out and for the love of god, work with it, because this is something that the audience will lock on to and won’t be able to drop. They will most likely remember you as the guy saying “Eh” all the time and not for the amazing content you are trying to convey.
To summarize it all up. Try to think of yourself as a rock star and compare your performance to a concert. Be sure to sing to the audience (Face the audience), make sure that your guitar solos sticks (Fix your demos), sing one song at the time (Stay on topic), don’t bring your embarrassing groupies on stage (Prepare your presentation machine) and make sure that you know the lyrics (Practice!). Follow these advices and you will most certainly become a better speaker!
A while ago I got into a discussion about documentation, can documentation help a programmer to be a better programmer? My view on this is simply no. I know that this is something that is debated all over and there are these two sides, either you are cheering for code documentation or you don’t. I cheer for the latter and I will explain why.
First of all a small disclaimer, I do love documentation of architecture, APIs and all of those project artifacts, they are essential to the project. But it’s not that kind of documentation I will address here, but simply documentation of source code.
So the first thing, comments is a bad thing because it excuses the developer if he or she write bad code. It tend to add acceptance for sloppiness because you can always explain what you are trying to accomplish with written comments in plain text. First of all, programming is a craft and we are craftsmen. We must act like it and try to improve ourselves. This being said, without the option of explaining yourself with comments in the code you need to focus on write good, simple and explainable code so that other developers easily can read and understand what the code is doing. A few examples;
Try
bool isConnected = false;
I strongly believe that focusing on good code instead of documenting it will help developers to be better and improve their craftsmanship.
Another bad thing about commenting code is that it will start to smell. We are all familiar with code smell, but comment smell is just as bad. Let me explain. Comment smell is something that will start growing alongside with the comments. The harsh truth is that in most systems where comments are used, the code will change but the comments will not. At first when the guide lines for how the code shall be written and documented is established in the beginning of the projects, the comments will be just fine. But when things start to change due to maintenance, quick fixes or sprints, more and more code will be changed without the developer changes the comments. This is comment smell, the comment describes something other than the code actually performs and that is really bad. It is bad since you can’t trust the comments in the system. If one comment is off, you can’t trust the rest. It’s just like when using unit tests, you must be able to trust them for them to be of use to you.
I have worked in a several different kinds of projects with mature software like maintenance and system reviews. One thing that I tend to find in all those projects is message handling in the code. No, I do not talk about sending messages to a MSMQ or anything like that, but the source code files being used as a chat where developers writes comments to each other. This is among the worst comments of all since they can indicate an issue, and when you find the comment you have no idea if it is taken care of or if is still an issue. For instance, the next example is a real comment that I found and that had been in the source for over 15 years.
“1994-10-11 We have a problem here that can crash the application. I don’t have time to fix it now so someone else has to do it //Jens”
Oki? Someone else? Who and when? This is BAD! This is a perfect example of comment smell. Issues shall be handled outside of the code in a structured way using post-its, TFS, JIRA or whatever system that can be used to keep track of issues, but not the source code!
There are an exception after all. If you are introducing a complex algorithm in the code and it is hard to understand it, then you should comment it. But then and only then, not with trivial code.
Just to wrap things up, no I don’t think that documenting the source code will help you be a better programmer. In fact, documenting the source code is documenting the documentation because in my eyes, the source code itself is the documentation for the system that explains how the compiled software works!
Don’t forget, you are a craftsman, the code you write is art, it’s built by your key strokes, and don’t waste time on documentation but constantly improve your skills!
“if you can’t write good code, you should not be allowed to comment it!”