I did spent some time adding new feature requested by my Wife. Links, in card details field, are now supported as real HTTP links, which could be opened. I did remodel slightly the Kanban Card dialog to support that.
The other new feature is the possibility of changing look of Kanban. The feature comes with easy way of adding own styles.
The video bellow is a quick overview of the new features.
How to update My Personal Kanban with your own styles
You need to create a css file with styles and copy it into: my-personal-kanban-folder/styles/themes/ folder. Name doesn’t matter, however you will need to use this name in last step. The default-bright.css and default-dark.css can be used as a starting point for your own styles.
Prepare image capture for the new style and place it in my-personal-kanban-folder/img/themes/ folder. It should be a jpg no bigger than 150px in width with the same name as the css file (you can see that there are default-bright.jpg and default-dark.jpg in that folder already).
Last step is to open the themes.js file from my-personal-kanban-folder/scripts/ folder (it will have a funny name like 5ebce75f.themes.js ) and add entry for your new theme. Name is the property that will be displayed in the Drop down. css is the property that will be used to find the css and jpg file prepared in steps 1 and 2.
My Personal Kanban is offline Kanban Board that runs within web browser.
Why Kanban for personal stuff?
Kanban is lightweight enough to bend to my personal lifestyle and to the way I do things outside work. I used a simple TODO list but I wasn’t happy with it.
Kanban gives me clear overview of things that need to be done, things I’m working on and stuff I finished. It also provides way of prioritizing the work (by color coding or bubbling the most important tasks to the top of the columns) and clear visual aid for reviewing tasks.
By limiting Work in Progress I can make sure I stay focused on task and finish it. By looking at the last column with things done I can give myself a tap on the back for achieving task completion.
I use Groovy a lot. It’s simple and easy to use, runs on JVM and saves me from Java verbosity. I also like the fact that it’s dynamic.
I do convert the maps into JSON when returning results to a browser. I don’t use anything fancy, just a couple lines of Groovy code to do that.
I’m a big fan of Kanban board. I prefer it over TODO list for all my professional and personal work. It’s clear to understand, doesn’t require extensive management process and most important offers great visibility of work.
I’m not going to focus on Kanban itself. If you want to read more about it I would refer you to few external links for more info:
Today is roughly 3 years since I’ve decided to sort out my email. Both, my personal email and my work email. I’ve decided to go 100% Inbox Zero. No exceptions.
I had a massive inbox full of stuff. I’m using Gmail for my personal mail and the Exchange and MS Outlook at work. Thanks to Google’s never ending storage I never removed a single mail from my inbox. It was the same at work. It started to bother me at some point for number of reasons.
I took me a moment to find things I was looking for
I was annoyed with the mess and the number of things in my inbox
I couldn’t organise myself based on my email inbox. Couldn’t decide what to do next.
About the same time I started to think of my problem I stumbled upon the concept of Inbox Zero.
How I’ve done it?
First thing was to actually reduce the amount of received emails.
Unsubscribing from useless marketing stuff and newsletters I never read and was never interested in.
I’ve created Labels in GMail and filters in Outlook to put less important informative things (like interesting newsletters, Bank statements, some billing info) into folders. This information is there, separately from the other stuff and I can easily get to it by navigating to a folder.
Last step was to archive everything else. This left my Inbox totally empty.
When I received something I was not interested I either tried to unsubscribe or mark it for my spam filter.
All the filters took care of putting interesting but unimportant mails into folders.
Every email I received become immediately my TODO email. I either answered it immediately or as soon as I could. As soon as I took an action I could archive the email and forget about it.
I find few advantages of having no emails in inbox.
The fact that my inbox is empty when I navigate to it leaves me with the peace of mind. I know that all the necessary actions I should be taking, I’ve done and I don’t need to worry about it.
Email is no longer only a way of communicating, it’s also a way for organising myself. I do actually send myself an email as a reminder of things I need to do. After three years of doing Inbox Zero, I know I will make sure that I will get to it as soon as I can so the inbox could stay empty again.
Lastly, the fact that there is nothing in the inbox and the fact that my Email TODO list is clear makes me feel good, gives me a motivational sense of accomplishment. That alone is an incentive for the Inbox Zero.
During my early years of software development I used to think of Code Reviews as a necessary bureaucratic monster, process designed to stop me from delivering the value and focus on pointing out mistakes.
My outlook at it has changed. There are many benefits of code reviews. Some of them that are more important for me:
increases quality of code therefore improves maintenance
facilitates sharing of the information and knowledge with fellow developers
improves my coding skills thanks to feedback
At RBS we are using Subversion and GIT as our SVC tools. We are using Stash to manage our repositories. Stash has a very useful features that could help setup the code review as a mandatory process, before the code is merged into the main branch. In this post I would like to show you how to set it up and how to use it.
Use case for code reviews
The use case for the Mandatory code review is taken from a real case brought at my work by one of the teams. The team was typical, Technical Lead, Senior Devs and Junior Devs. They wanted to leverage the Code Review goodness for learning.
What the users wanted to do is:
allow only specific users to be able to modify code in Master branch of GIT repository
allow everyone else on the team to create their local branches and push those branches into remote repository
have the ability to raise a code review of changes made on a user branch before merging the changes into the Master
have the ability to comment, decline the changes
once the changes were accepted to allow anyone with enough permissions to merge the code
Preparing repository for code reviews (or for Pull Requests)
First thing to do would be to make sure that all the people in your team are Contributors to a project. I have a group of users in Stash called superheroes. I need to set them as a Contributors on my project.
Project level permission settings
What I’ve done above means that everyone superhero in the group would be able to contribute to the project. The next step will restrict the changes on Master branch and allow it only for a specific user (in our case, Superman).
The above action will result in only Superman being able to make any changes on Master.
What would Batman do?
For Batman (the user that is restricted on Master but allowed on Project level) to be able to work he needs to work on a branch, push that branch into Stash and create a merge request (Pull request).
Creating the Pull Request
When Batman finished working on the feature he would like to Batmobile to become mainstream and be adopted by all Superheroes. What he needs to do is to merge hist feature into the Master branch. We know already that he cannot do it as someone need to review his changes. In our case it’s the Superman.
Batman creates a Pull Request.
What Superman will see once he is logged into Stash he can review the Pull Request, approve them, decline, comment, etc.
Once the request is approved, Superman or anyone else with the permissions to modify Master can merge it.
Possibly worth to mention the fact that it is possible for anyone to review the changes as it is possible for Batman to request anyone to be the reviewer, however, only the users with enough privileges will be able to merge the changes.
The above setup leverages the feature of Branch Permissions in Stash. Anyone who would like for changes to be merged into the Master branch will need to go through Code Review.
Wishing you many happy reviews and much more learning.
We have a rather large farm of build agents. Some of them are specifically build to suit various build requirements (for example OS, or Browser version). However, majority of the Agents are generic and could be used by any build and project.
By default we don’t have Gradle distribution installed on those TeamCity agents. TeamCity doesn’t come with bundled version of Gradle either. We could install versions of Gradle on the Agents, however it’s impractical due to the number of the Agents and the fact that there is many distributions of Gradle that could be required.
Solution to that problem could be Gradle Wrapper. Gradle Wrapper contains few files that you should include as a part of your project.
In this article I will introduce Gradle Wrapper, how to use it and how to set it up in TeamCity so it works behind firewall/proxy in enterprise network.
The main role of wrapper is to Download distribution of Gradle and execute the build independently of the platform.
The interesting bit is that you can use Gradle to generate those files.
Creating Gradle Wrapper files
The Gradle Wrapper files could be copied from another project or generated using Gradle Wrapper task.
The task will generate folders and files that could be seen in the top picture of this post.
Using Gradle Wrapper
You should be able to use Gradle Wrapper in the same way you use Gradle from your command line.
When you execute the Wrapper for the first time it will download the distribution first (just as you can see on the picture above).
You could face first problem if you are inside a corporate network, behind a firewall and proxy.
Setting Wrapper to work behind Proxy
There are two ways you can address the issue:
Setup proxy details on your Gradle Wrapper Script
Provide Wrapper Distribution URL somewhere reachable within your corporate network
To setup proxy details you could modify gradlew and gradlew.bat files. Top of both files contain DEFAULT_JVM_OPTS system variable that you could set. For example:
## Gradle start up script for UN*X
# Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script.
DEFAULT_JVM_OPTS="-Dhttp.proxyHost=proxy.host.net -Dhttp.proxyPort=8080 -Dhttp.proxyUser=proxy.user -Dhttp.proxyPassword='awesome-password"
To provide alternative Gradle Distribution URL you can set it up before you generate Gradle Wrapper files in your task of the build.gradle file.
The benefits of first approach is that you don’t need to host Gradle distribution anywhere within your network. The minus is when proxy requires authentication, you will need to put credentials in the file.
The benefits of a second approach is that you don’t need to modify gradlewscript files and you don’t need to provide proxy user credentials. Also, distribution is hosted internally which potentially could mean faster downloads. The downside is the fact that you need to host it somewhere internally accessible via HTTP protocol.
Setting up TeamCity build
The task is relatively simple with only one hurdle to overcome. Once the Gradle Wrapped downloads the Gradle distribution, where does it actually put it, and where will the dependencies downloaded during build phase go.
Note that I’ve not declared where are those directories that the downloads (Gradle distributions and build dependencies) will go. We can set this up in two places:
TeamCity system property for the build
Setting the Wrapper Properties file
The gradle/wrapper/gradle-wrapper.properties file could be modified directly or setup during the prepareWrapper phase.
Benefits of this approach is that you don’t have to configure anything specific in TeamCity. The downside is that you need to know in your script the details of Agent file system.
Setting the TeamCity system property
The system property to set should be the one referenced by gradle-wrapper.properties which is GRADLE_USER_HOME.
At this point it is important to mention one thing: if the same GRADLE_USER_HOME is used within different builds, it could potentially save time on downloading Gradle distribution and build dependencies.