Friday, April 21, 2017

Feature Toggling

From Wikipedia -
feature toggle[1] (also feature switchfeature flagfeature flipperconditional feature, etc.) is a technique in software development that attempts to provide an alternative to maintaining multiple source-code branches (known as feature branches), such that the feature can be tested, even before it is completed and ready for release. Feature toggle is used to hide, enable or disable the features, during run time. For example, during the development process, the developer can enable the feature for testing and disable it for remaining users.[2]
Continuous release and continuous deployment provide developers with rapid feedback about their coding. This requires the integration of their code changes as early as possible. Feature branches introduce a bypass to this process.[3] Feature toggles are an important technique used for the implementation of continuous delivery.
The technique allows developers to release a version of a product that has unfinished features. These unfinished features are hidden (toggled) so they do not appear in the user interface. This allows many small incremental versions of software to be delivered without the cost of constant branching and merging. Feature toggles may allow shorter software integration cycles.[4] A team working on a project can use feature toggle to speed up the process of development, that can include the incomplete code as well.
I have been looking at implementations to accomplish this and came across Togglz - Features flag for Java.   Looks pretty easy to use.   This looks interesting as well Togglz aspect with Spring Boot - Insane Programming.  

I am looking to try to implement feature toggling and would be interested to hear about your experiences.   

Tuesday, November 15, 2016

Context switching kills productivity... Here are a few things I found helpful to get stuff done.

I read this post today and completely related to it...

It feels like this is our nightmare.   Context switching, meetings, emails, instant messages, phone calls, more meetings,  more emails, more distractions.    It is sometimes an almost an impossible task to make progress on our tasks, goals, innovations.....   

If I get an hour or two of focus during the work day it is a miracle.   Feels like the only way to get things done is to work at 10pm at night after family stuff is done and the emails and other distractions have come to a halt.    

Here are some things that I have tried and seem to help me to be more focused during the workday without going completely dark.

  • Leverage a persistent team chat software like (Slack, Hipchat, Flowdock, etc.)   I am currently using Flowdock at my current job and it has been a great tool for my team.   We have been able to eliminate almost all internal team emails.  Instead of trying to catch up with tons of emails we can now goto one place to see what is going on with the team.  
  • Block off time in the calendar.  
  • Use Lync/Skype Busy and Do Not Disturb.   
  • Pomodoro Timer.   Pomodoro Technique® and Scrum: Objective IV | Devoted Developer  I use the timer for when folks come by my desk and I really need to focus.  A Pomodoro is usually 25 mins.  If I am in the middle of one and someone stops by I quickly look at the timer and ask them if I can stop by in X minutes when my Pomodoro is done.   Most of the time this is acceptable.
  • TDD.  TDD allows you to continually develop in an iterative fashion with tests that not only make sure the code does what I expected to do but also makes it easier to stop/start developing.   Without this it takes allot longer to figure out where you left off when you get back to developing.

I am interested in hearing what others are doing to help focus and get things done in our challenging environment of distractions.

Monday, December 21, 2015

Try to avoid using Static Methods in your code

I have been coming across allot of static code in the projects I work on.  It really makes practicing TDD, or any unit testing, a pain because static methods are not easily mocked.   Static methods also force your code to be highly coupled.  

A better approach is to not use static methods and instead use dependency injection.   This lends itself to being a better testable decoupled approach. 

Here are a few articles I have come across that do a pretty good job better explaining why you should try to avoid using Static in object oriented languages:

Thursday, December 3, 2015

The Obligations of a Programmer (Bob Martin)

I read this for the first time today interested to hear others thoughts.   From... Clean Coder Blog

We rule the world.

We programmers. We rule the world. We write the rules that make our society work.
Think about it; and think about it carefully. Nothing happens in our society without software. Nothing.
It's certainly true that the Earth turns, the Sun rises, the rain falls, and the tides recede and advance without the aid of software. But in our society, virtually nothing happens without the involvement of some kind of computer program.
Without software: Phones don't ring. Cars don't start. Planes don't fly. Bombs don't explode. Ships don't sail. Ovens don't bake. Garage doors don't open. Money doesn't change hands. Electricity doesn't get generated. And we can't find our way to the store. Nothing happens without software. And what is software? Software is a set of rules.

We rule the world.

We don't quite understand this yet. More importantly, the world doesn't quite understand it yet. Our civilization doesn't quite realize how dependent it has become on software -- on us.
Healthcare.gov, Knight Capital, Natwest Bank, and Toyota were wakeup calls; but each time we hit the snooze button and went back to sleep. But the sleep can't last much longer. At some point, probably very soon now, our society will realize, to their horror, just how much responsibility, and just how much power, they have placed in the hands of programmers. In our hands. It will slowly dawn on our civilization thateverything has been handed over to us. Everything!
And if they are smart, it'll scare the hell out of them.
And it should scare the hell out of us too.
Imagine what we could do if we were to unite. If programmers around the world united under a single cause; we could dictate terms to the rest of the world. And the rest of the world would have no choice but to comply.
If we wanted to, if we were willing to organize and plan, there would be no force on the planet that could stop us. Anyone who tried to stop us would suddenly find that none of their cell phones worked, none of their gas pumps pumped, none of their credit cards were valid, none of their fighter jets flew, none of their cruise missiles cruised, all of their bank accounts were overdrawn, none of their bills had been paid in a year, there were warrants out for their arrest, and there was no record of them ever being born.
Perhaps you think I'm exaggerating? Perhaps I am. Perhaps.
But the fact remains that we programmers are in a position of tremendous power that the people whom we serve do not well understand; and that we hardly understand any better. And so the time is certainly coming, if it has not already come, for us to make some decisions. What kind of rulers do we want to be?
Will we ignore the power in our hands and remain a disorganized band of rumpled hapless vagabonds? Will we continue on our undisciplined course, blown by the chaotic winds of business and government, until one of us finally blunders badly enough to wake the sleeping giant of government regulation? Or will we recognize the power we have and decide to use it? And if the latter, will we use that power for good, or for evil? Or will we take responsibility for that power and promise only to wield it in service to our society?
With great power comes great responsibility. We, as programmers, should recognize that responsibility and determine to be conscientious servants of our society. We should set the limits and standards of our behavior. We programmers, not our employers, not our governments, should decide what it means to accept the responsibility of the power that has been placed in our hands.
Think of the military. We give weapons of tremendous power to the people in the military. Those people could turn those weapons upon us and rule us absolutely; and we would have little choice but to surrender and obey. What keeps that from happening? Only their code of ethics and their sworn duty to use the power we have given them on our behalf, and at our request, in order to protect and defend us.
So should it be with programmers. To protect our society from the power they have unwittingly ceded to us, we should adopt a code of ethics that describes our sworn promise and duty to humbly use our power to serve.
What would our code of ethics look like? No one person is in a position to write such a code; but I think the rough outline would contain the following points:
  • We will not purposely cause harm.
Of course this is nothing more, and nothing less, than a restatement of the first rule of the Hippocratic oath. It's hard to improve upon something that's been around so long. Each programmer will have to interpret the definition of harmaccording to their own moral code. Some folks may believe that working on weapon systems is the best way to prevent or minimize harm. So be it.
  • Our software will be well-written for its purpose and lifetime.
Again, this could be interpreted many different ways. We could add statements like:We fully test our software. or We practice TDD. or We follow SOLID principles. But the bottom line is simply that we go home every night, look in the mirror, and are proud of what we accomplished that day. We never feel like we have to run home and take a shower.
  • We behave with Honor and Discipline.
No code of ethics would be complete without a statement about personal behavior, and behavior within a group or team. We, as programmers, need to earn the respect of our customers and peers; and that requires a faithfulness to the truth, and predictability of behavior. Honor and discipline.

The Obligation of the Programmer

What would our oath to that code of ethics look like? What promises would we swear to keep?Consider this oath which I have adapted from the Order of the Engineer
I am a computer programmer, I take deep pride in my profession.
  • To it I owe solemn obligations.
  • All human progress has been spurred by the genius of those who manipulate information.
  • By making it possible to manipulate vastly more information than ever before, programmers have created enormous benefits for human society and greatly accelerated human progress.
  • Were it not for the accumulated knowledge and experience of those programmers, mathematicians, and engineers who came before me, my efforts would be feeble.
  • As a programmer, I pledge to practice integrity and fair dealing, tolerance, and respect, and to uphold devotion to the standards and the dignity of my profession, conscious always that my skill carries with it the obligation to serve humanity by making the best use of the precious resources under our stewardship.
  • As a programmer, in humility and with the need for guidance, I shall participate in none but honest enterprises.
  • When needed, my skill and knowledge shall be given without reservation for the public good.
  • In the performance of duty and in fidelity to my profession, I shall give the utmost.
- The Obligation of the Programmer
We are the rulers of the world. It's not a position we wanted. It's not a position we anticipated. But here we are. We write the rules. We hold the strings. Now we have to decide what to do with them.

Monday, October 5, 2015

Great presentation: Are You a SOLID Coder?

http://www.infoq.com/presentations/solid-principles

Great presentation.  Check it out.