I recently had a first-hand experience of thrashing while in the middle of a product’s release cycle. As much as I’d like to talk about circumstances, it’s best if I’ll just point out ways on how to get out of it.

1. Focus, focus, and focus on shipping the product.
2. Do not listen to goals^{^dreams} that doesn’t help with the product shipping on the target release date.
3. Wake up and face reality.

Focus, focus, and focus

I could’ve done a lot of things to get out my demotivated state, but I thought that the best thing that I can do is to keep on focusing on shipping the product on the release date. Focus by pushing myself to do emotional work and not worry about other things but to ship the product. Focusing on shipping the product is the only way to actually ship the product.

Be deaf to pipe dreams

There were times when I felt that some of my team members are getting way too ahead of themselves. Don’t listen. Don’t even take note of those futuristic (and sometimes, non-realistic) ideas. Those ideas are not 1.0 material so there’s no point bothering myself, or the team, with them. If those ideas are really awesome, or important, they will come back to remind us after we ship 1.0. Until then, we needed to focus on those 1.0 release goals.

Reality

Lastly, it’s difficult to be perfect when you have tight deadlines and a release date looming. There were times when I thought we could’ve written parts of the code a bit better, refactored a bit better, and tested a bit better. I was demotivated for a while that we had hacks here and there and all I could was to add FIXMEs. Shame. But we’re not going to ship it on the date if we kept it pure, if we kept it clean. We had to ship, and unfortunately, we had to live with those technical debts. And that’s just reality.

Publishing a ClickOnce installer in Visual Studio 2008 is a hit-and-miss, and most of the time it’s a miss. It’s either you get build errors due to missing intermediate files, or if it’s successful, the application won’t launch due to a missing application.xaml file. This shouldn’t happen, and there’s not much you, the developer, can do unless you know how VS 2008’s ClickOnce publishing works.

But, there’s a workaround and that is to use MSBuild to generate your installer. On a single project solution, this should be as easy as typing msbuild.exe /target:publish in the top-level solution folder. If you have other projects within the solution that you want to generate a ClickOnce installer of, just go to that folder and use MSBuild to publish.

There were a few times when I wanted to follow a specific tweet in Twitter because I’m interested in what other people will say. For example, if Brad asks if there are restaurants nearby that serve Laksa, I would be interested in what his followers will recommend as well because, I too, like Laksa[0].

This feature has more value to me. It’s like Quora but for tweets.

[0] Yes, you can use geolocation services but I hope you get my point.

Facebook Lawyer `Unsure’ Whether Zuckerberg Signed 84% Ownership Contract – Bloomberg
http://www.bloomberg.com/news/2010-07-20/facebook-lawyer-unsure-whether-founder-mark-zuckerberg-signed-contract.html

(Sent from Flipboard)

Watching the WWDC keynote made me think why it’s more interesting than the Android Google I/O keynote: hardware. And this is something I hope Google will introduce in I/O 2011 – showcase handsets or introduce handset vendors to speak about future handsets in the pipeline that will run a future version of Android, and introduce the important features of both hardware and software. It’s hard to imagine how Froyo (Android 2.2) will look like on a future handset (the demos seem to be using N1 most of the time). It’s also difficult to compare iPhone 4 against the handsets used during the I/O keynote, because it’s obvious which handset is sexier/shinier.

Posted via email from metahack

“Chuck Norris doesn’t bug hunt as that signifies a probability of failure, he goes bug killing.”

– Hudson – Chuck Norris plugin

Posted via email from metahack

I use DocProject for automated documentation builds of one of the projects I’m currently involved in. DP takes away much of the manual doc-generation tasks as it provides a VS (Visual Studio) project for the documentation project and is integrated in the project’s solution. This allowed me to incorporate the documentation build as part of project build (using msbuild), which is already integrated in my Hudson deployment

The doc build is not as seamless as it should be and I’ll be highlighting the additional tasks required to build the doc project so you don’t spend half of your day working out the build failures for the last few hours like I did

Environment Variables

Before you push your changes, make sure you add the environment variables DocProjectBuildPath and DocProjectPath in your project’s configuration in Hudson. The value of these two variables can be found in Window’s System Properties. It’s strange that this wasn’t already in the doc project’s documentation. Without these two variables, msbuild will look for the target files in your C:\.

Leading dot (.) 

I started Hudson with a default configuration – with HUDSON_HOME pointing to ~/.hudson. That shouldn’t be a problem but one of the build steps (there are 12 steps!) to build the doc project involved generating a .chm file for Help 1.x. Who would’ve thought that you’re not allowed to have dots (.) in front of your folders? Moving my HUDSON_HOME to something more sane fixed it for me. 

Posted via web from .plan

Testing Internal APIs may sound superfluous but it’s necessary. It increases the team’s confidence in the codebase as well as be more creative with regards to maintaining and refactoring the codebase.

In C/C++, the symbols of internal APIs are exposed in Debug builds so these can be unit tested. In .NET, these internal APIs need be a ‘Friend’ and use the InternalsVisibleTo Assembly instruction like the following

<Assembly: InternalsVisibleTo(“MyUnitTestProject”)>

That’s all there is and you can start unit testing your project’s internal APIs. See http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx for more info on InternalsVisibleTo.

Posted via web from .plan

Posted via web from .plan

This morning I started to do a brain dump in Evernote rather than Google Docs, which is what I normally used. Google Docs is my preferred application for note-taking, brain dumps, and more recently, for general-purpose document archiving (I still use Dropbox for personal stuff).

But this morning was different. I asked myself why did I do it in Evernote rather than Docs? The first thing that came to my mind is that I don’t need another tab in my browser window. I already have 30+ tabs in it and it’s getting difficult to get to a manageable state.

Secondly, I realized that using/writing in Evernote’s desktop app just feels more comfy and I feel more focused. Being in a browser with Docs also make me watch the keys I press. I frequently press Ctrl-Q which kills my browser (Chrome) and I had to reload all 30+ tabs to restart again. Productivity kill. With Evernote, it’s just one app and it wouldn’t take too long to restart it.

Perhaps, I’ll try to work on my use-cases for Evernote more. My last post gave me insights on what I’m doing wrong with EN and what I should be doing in it. 

Posted via web from .plan