You kn0w, I am amazed by abundance of videos and tutorials out there that show you, how “easy” it is to create a mobile app. Sure, creating a “Hello world!” example with a few fields and a progress bar is not difficult, but that is hardly a representative app. In real world, you would want user to authenticate, you would want to store some user data (you know, in case he or she decides it is time to wipe the phone and then regret the decision), you would want to offer some payable services to those users and differentiate between free and pro users etc. etc. Yet, you don’t see tutorials for that. And you know why? Because those things are hard to do right.
In last few months I have been assigned as a mentor to young developer who wanted to work as a student for our company. This is my first foray in being a mentor to someone, let alone a prosperous young talent. The first thing when I was told about this, panic kicked in. But then I started thinking about the time when I was a young developer starting out. What would I want to know? What would I want to learn?
Teaching someone a specific technology is pointless. So what could I teach my apprentice that he can, hopefully, take with him for entire lifetime?
I narrowed the list down to four points. So, to you young-lings, I’ve got this advice to offer:
- Think first, code later.
- Learn how to use version control and bug tracking software.
- Listen to your elders.
- Question everything.
- Get out of your comfort zone.
I’ve been meaning to write this post ever since I read Rands post entitled Bored people quit (and I apologise to the original author for blatantly stealing the title). As far as I agree that boredom is important factor when people decide to quit, years of observation and experience brought me to conclusion that there is one more important reason to quit. Annoyance. Pure and simple annoyance.
I have been quiet for a while now (and I appologise) for two reasons. One was, that I spend 4 days abroad and another that I increased my studies for final MCPD web development exam (Microsoft 70-519). Yes, I know the certification will soon be useless as MCSD is going to take over. But (and you knew this was coming), I have been slowly certifying myself in .NET web development starting way before MCSD was introduced. Since I don’t like leaving things undone, I decided it would be best to complete current certification path and then upgrade.
Anyway, to cut long story short. From this day onward, I have reached MCPD Web Developer 4 certification and you can expect more posts from me in near future.
A few years back, I got suck into a conversation of my colleagues on book reading and it surprised me. And not in a good way. In a conversation of six, four of them didn’t read books (apparently due to lack of time) and one read only popular Sci-fi and fantasy books. The remaining one was me. I am far from being well read, but I still try to read a few books a year on tech and non-tech topics.
If not for books, techies definitely follow blogs. Don’t they? Not really. One person didn’t read blogs. Two followed blogs, but not tech ones. The remaining three had a daily routine to browse most popular blogs and find others, if work took them that way. Looking at results one can conclude that three developers out of six participating in the conversation (a stunning 50%) didn’t have a clue of what is going on in their field of expertise.
I first met Trac several years ago at my previous gig for a cloud project we were developing at that point. Prior to that, we used some in-house support tool developed in Lotus Notes. Prior to that, I used Notepad. And let me tell you, everything you use for issue tracking is fine, as long as you write it down. In these days, Trac seems a bit archaic. After all, there is Jira, there is FogBugz, there is Redmine, there is TFS, to name a few. But the issue here is not in what you use, the problem is how to use it. Issue tracking and project management systems are only as good as users using them. This simply means that the best tool in the world won’t help you, if your users do not know how to use it. [Read the rest of this entry…]
Remember the last time your boss roamed into your office/cubicle and asked you to add this one tiny feature to your project in a week? You were tempted to say it is not possible to do it in the time frame, but then you took into account that it looks and sounds as a small feature and it will probably take you only half the time to do it anyway. Also, it is difficult to say “No” to your boss, right? So you said: “Sure boss, I can handle it.”
In the end, what could possibly go wrong?
To be honest, I have been meaning to write this post for years now, but never got around doing it. It took a recent incident (yes, let’s call it that) to remind me of this topic.
You know, priorities are funny. We are taught about priorities since our birth, yet, when we reach adult age, there are still people who seem totally incapable of understanding and handling priorities. The problem is that priorities are highly subjective and totally dependent on a person owning a task. That is why, you never ever let customers set priorities when reporting issues. For them, every issue is uber-important and thus has high priority. In reality, fixing a typo on an internal web page that only 1 person visits once per month can hardly be as important as let’s say, public application crashing, but that won’t stop people calling you up every 2 minutes and asking why the typo still remains.
But I understand all that. It is the same problem when you call admins that one of your specialized test servers is not working correctly and they don’t focus every inch of their attention to it. Understandable, they have more important work. What I don’t get is developers refusing to assign priorities to tasks assigned to them. There are so many benefits related to priorities. You get a better overview of which tasks need to be solved now and which can wait (and which can be thrown out and buried in the yard). You get better chance of hitting the deadline by not doing the tasks that are simply not important. You get more precise deadline. And you get to see if you have been “taking one for the team” a bit more than others and then complain to your boss.
But no, developers and project managers tend to leave priorities to default and then pretend that everything is equally important. And then you get developers painting a background of a textbox pink instead of churning away on important feature that will bring you profit and reputation. But hey, pink textboxes are important as well.
Sooner or later, your .NET web application project will gather helping hands and it is at that point that you will realize that deployment from Visual Studio is just not good enough. Yes, I know Microsoft did a grand job with their deployment scheme in Visual Studio, but let’s be honest. That only works if you are a single developer working on a single environment. As soon as you have to do regular integration, testing and production deployment, Visual Studio fails. More hands on a project only makes things worse. This is not a critique. Visual Studio is development tool, not a continuous integration tool.
So, to positively answer Joel’s second question, you will need some sort of build and deployment automation. Sure, you can use TFS, but that costs money and a supercomputer and let’s be frank, most small shops cannot afford it. So, what you will end up is either some open source CI tool like *cough*CruiseControl.Net*cough* or write your own scripts. Whatever you use, you will find yourself in a peril building and deploying .NET web application. Why? To publish .NET web application building it and copying it to server just won’t work. The easiest way to do it is to create a package and deploy it to your IIS using MSDeploy extension. So, how do you go about that?
To create a package execute following command line expression:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe MyWebApplication.csproj /T:Package /P:Configuration=Release;PackageLocation="D:\path_to_my_project\bin\MyWebApplication.zip"
Obviously this is for 64-bit systems using .NET 4.0 and 4.5.x. You can package your app for 32-bit systems using same expression by just removing 64 from Framework64 part of MSBuild.exe path.
Now that you have your deployment project ready, check MyWebApplication.SetParameters.xml file located at D:\path_to_my_project\bin\ folder and change IIS web site and name, if needed. Also, connection strings used are in that file, so you need to pay attention, if everything is set accordingly. Finally, you are ready to deploy:
D:\path_to_my_application\bin\MyWebApplication.deploy.cmd /Y /m:http://myserver.mydomain.msft/MSDeployAgentService /u:MYSERVER\Administrator /p:supersecretpwd
There are ways to run deploy command file with another user, but that will take some server tweaking on your side. Anyway, after the command completes, you have a running application.
For a side project, I am working on in my spare time since college, I needed to create a splash screen. Finally. Eleven years after version 1.0 and we are thinking splash screen. Anyway, the splash screen must contain a custom image as a background, a progress bar to display how the initialization is progressing and something that will show every step of execution. Steps completed must be stacked on top of current step. Needless to say, application is written entirely in C++ using MFC framework and said splash screen, naturally, must be part of the application and not a separate project.