Browsed by
Tag: story

Hello world, again! (Broken links)

Hello world, again! (Broken links)

I have moved by blog over from blogger to WordPress!

As these two platforms are not exactly compatible,  old links are broken, please give me some time to fix them. I am working on it.

How do I access the old blog pages?

Meanwhile, you can:

  1. Try replacing the year and date between the domain and the actual blog you are looking for with link with ‘/blog/’.
  2. If you are logged in to WordPress, the blog may show you a search button in upper right corner. In that case try searching for the blog.

Please feel free to use comments on this page to report broken links.

Experience: Introducing JMockit To The Team

Experience: Introducing JMockit To The Team

Like many codebases out there, our codebase at work had a backlog on unit & integration tests and it was high time we covered it up. So one fine day, it was decided that we shall no longer accept code without tests. Then the question of ‘how do we write tests’ came up. As one of the architects on the team I introduced the methodology of unit/integration testing and a mocking library (JMockit) to aid in cases where testing could be difficult without one, conducted trainings and hands-on sessions for everyone on the team, set up a peer review process and we were ready. That is all there is to the history of the situation we are in. Well, we are talking about a large team here, some eighty people working on a large codebase as a whole, although divided in multiple microservices.

Today, almost every test we have has a mocked class, and an expectation set on some dependency. Many tests verify how many times a particular internal/private method or a method on a dependency was invoked, some have VOs mocked, or have assertions on return values inside verifications block. A few have gone to the lengths of mocking constructors of certain objects because there was no way to inject them into tested class. We are not even considering the private and static method mocks here.

When I look at the tests that we have today, and look back on the last few months, I wonder if I made mistake while introducing the mocking tool. In the trainings we had, we discussed the purpose of a mocking tool, issues due to overuse, indicators of overuse; heck there was even slide dedicated to this in the developer induction we have here. Architects were involved in many code reviews and tried avoiding these pitfalls, but clearly it was not enough.

Tests are supposed to improve the design of the code. Since the highly tangled, coupled classes, classes breaking SRP (Single Responsibility Principle) are difficult to test, we tend to fix them. As the size of the class increases, the functionality it has grows making it difficult to test, so we split it. As the dependencies being created makes it difficult to test, we change the class to allow injecting them. We end up splitting large methods, redesigning methods with side effects, removing unneeded code, decoupling from the libraries all for making the code testable and effectively get cleaner, maintainable, verifiable code. All of this, only if we wrote tests correctly.

If we started modelling our tests to match our code, we not only lose all the benefits, but the tests start becoming coupled to our code. That brings down the speed of refactoring or new development because every time we change code, we need to change the tests to match the implementation. That brings down our overall productivity. And finally blaming it on tests, we would stop writing them altogether. Back to square one! Mocking tools have a purpose, but if we mock everything, we get our tests tightly coupled to the implementation, adding to the problem. Mocking simple data-structures and VOs is not meaningful, we never test their methods separately, they are not supposed to be tested. (And yes, VOs are data structures, let us not get into that here.) Mocking external libraries is risky, because we then verify their actual behaviour only at runtime, which is exactly what we are trying to avoid by writing tests.

JMockit is a powerful tool, a little too powerful, and harmful if we are not careful. Despite the misuse that we have done, it could do all those things is itself marvelous. I am not convinced to blame it on JMockit, it is as Uncle Ben said to Peter Parker: ‘With great power comes great responsibility’. What we did, is our fault, we should have been more responsible with it. I wish I could go back and change the way we used it, or overused it, but our life is not a Git repository.

Luckily though, we have identified these issues and their severity before they start heavily weighing us down. What we need to do first is avoid more such tightly coupled tests from getting in. The course of action now seems like along with training the team on how to be more responsible with tests (which by the way needs to be a continuous process), we need to identify reviewers and train them on spotting such instances. Revising the review process to have reviews through identified reviewers and not just peer reviews.

Participating In A 24 Hour Hackathon

Participating In A 24 Hour Hackathon

Just returned from a 24 hour hackathon, sleepy, red-eyed, tired, exhausted and yet writing this post. You know why? Because I skipped it the last time, and the time before, thinking I will do it the next day and that sleep was more important, but never did it. Not going to make the same mistake again. So here I am.

For those who are unaware of what a hackathon is, it is an event where dreamy eyed people enter and leave with red eyes, it is a single night sprint where people come together to build something that they believe will make them a billionaire or like Silicon Valley series mentions time and again, ‘will make the world a better place’! Well, jokes aside, a hackathon is an event / competition where teams / individuals build software / hardware in a single sprint of 24 hours. Hackathons have a theme, ranging from generic things like improving community to specific themes like solving a specific delivery problem the company faces. Some hackathons are closed, conducted only for the members of an organization, some are open to all. Some hackathon focus on profitability of an idea and implementation, teams winning sponsorships from investors, and some focus only on ideas and imagination of the participants. All in all, a hackathon is a developer’s Disneyland!

If you feel like you have ideas, but no time to develop them, try them out or run them by other people? Hackathon is the place for you to build your dream concept into reality. You are an amazing developer, you can punch in code and get things working in no time, hackathon is the place for you to show your skills. You like to interact with people, share ideas and learn how people feel about them, hackathon is the place for you to validate your product. You have a concept, but are looking for skilled brains to develop it, hackathon is the place for you to spot skills and recruit them. You are a nerd, introvert, who loves to code (the stereotypical software developer), walk right in, there are many like you in there. You are a night-owl who believes that sleep is for ‘cats’, you will fit right into a hackathon. Imagine a place which provides electricity, wifi (I have your attention now, don’t I?), food, seating space and all else you need, and leaves you undisturbed for 24 hours with the freedom to build your dream into reality, now that is a hackathon. (Put like this, it sounds better than Disneyland!)

Now let us say you wish to go to a hackathon and ‘make the world a better place’, you need to have a plan, like everything else. There are things that you should and should not do. There are things that you should and should not carry. I have over time built a list of items I carry to a hackathon, and like other ideas validated it against others during the hackathon. So what we have here is a list of items people in general carry, not every item will apply to you though. It is like a camping list, but for geeks.

Preparing for the Hackathon

  • Prepare for your idea: Think, elaborate it, plan it. This is also a test of your agility, all your skills in iterative, agile, development are going to be tested. Know that a 24 hour hackathon is 3 working days time on your hand, it is a lot, plan how to utilize it best.
  • Choose the right team: Long hackathons tend to be team games. Choose your team wisely. You should have compatible yet slightly overlapping, targeted skills, and equal passion. You probably do not need a marketing executive or the so called ‘product owners’ on your team unless the idea is from their domain. It is not a conference, you do not get a booth there. And passion, yes, you do not want your team members jumping into sleeping bags at the chime of 10 only to get up at 6 next morning.
  • Identify what open source projects can help you, know how to use them. Play around with them. May be send a pull request for missing features. But know what is going to help you get it done faster and plan for it.
  • Set up your machines. You do not want to be downloading a database server or creating cloud service provider accounts at the hackathon.
  • Set up productivity tools suitable for your idea. For example, get accustomed to using a clipboard manager; write and keep handy scripts to automate simple tasks like starting db, launching db shell, clearing tables, generators for various frameworks etc.

Packing for the Hackathon

  • Laptop: Of course! Humans are yet to build a computer one can use to develop software on in thin air, unless that is what your idea is for the hackathon.
  • Laptop charger: You will be surprised how many people forget this. Although your machine has juice for one work day, it is not enough for a hackathon. If you think of it, it is actually 3 work days there. And you don’t want to be making ‘connections’ by asking people for charging cables.
  • Phone & charger: You are going to interact with a whole lot of people, do carry your phone to note down numbers, not everyone brings the business cards, it is not a conference. Hackathon is for thinkers and doers not talkers, yet the excessive use of phone screens drains them, so do carry your chargers. Some hackathon venues do provide charging stations, you can check to confirm if there is one.
  • Peripheral devices: If you prefer to use an external mouse, drawing pad, a VR headset or whatever you need, carry them. Pack the devices you need to build your idea, like a raspberry-pi, a hovercraft kit or whatever. Keep pen-drives handy. You can check or request if the organizers provide an external screen, it will be too huge to carry anyway. It is all developers and geeks there, I would not blame you if you do not trust the security of the wifi there. In that case, carry your own portable hotspot.
  • Identity proof: You have registered online, but the organizers need to know who you are before you can enter.
  • Toiletries: Do I need to explain? Just don’t stink, you do not want to be remembered for that.
  • Medicines: If you are on medicines, do not forget to carry them. If you get acidity by staying up late, carry antacids. You get headaches, carry a mild pain killer. Have allergies? Carry an antiallergic. Afterall it is a competition, you want to be your best throughout.

Wearing for the Hackathon

  • Wear something casual and comfortable: If suits are your thing so be it, but remember you are going to be scratching your head over a lot of things in the next few sleepless hours, be comfortable. You do not want to be scratching other parts of your body due to uncomfortable clothes. You do not need to look pretty/handsome, make-ups and hair-sprays are not required, your personal comfort is.
  • If you are representing a startup, wear them on! Hackathons are good for creating awareness and hype.
  • It is okay to wear your lucky accessories, but limit it to that, avoid the temptation to wear superman under your clothes.

Hacking at the Hackathon

  • Not literally. Do not hack others’ devices, you can get banned from the premises or worse.
  • Divide your hours like they were days. 4 hours represent your half day of work in there. Have regular discussions.
  • Divide your tasks and identify interfaces where your tasks meet.
  • Use version control systems extensively, If it is a hardware product, keep taking photos from all angles. At hackathon, I prefer to change the way I commit; usually I commit often but push after cleaning. At a hackathon I commit and push extremely frequently, on every unit completion. It would not be an exaggeration to say that make the version control system your undo log. This also help prepare for an unfortunate event if your machine decides to take a nap while you are banging the keys.
  • Ban headphones on the team. Unless there is interaction, there is no team.
  • Plan your long breaks, like lunch, dinners and snacks to be in sync with your discussions.
  • Take frequent breaks apart from the discussions, individual or team breaks, but get up and walk around. I drink a lot of water, that forces me to take frequent breaks and helps avoid health issues as well. It is also a good idea in your day to day work.
  • Do not sit it through, walk around, jump around, interact, stay active and awake.
  • If you can, take naps in between. Just make sure you allow your partners to pour a water bottle on your head to wake you up, just in case. You do not want to miss all the fun by sleeping through.
  • There tend to be side events every few hours in long hackathons, participate in them, get to know people.
  • Meet people. You will find a whole lot of them are working on something amazing. You might end up meeting your next employer, co-founder, your living idol, or even your soulmate, if you are looking for that. You never know. All those coming to the hackathon tend to be there for their passion.
  • Have fun. Win or lose, unless you have fun at the event, it is pointless. Have what fun means to you. No one forces you to take part in any of the events or to talk to people, if you just wish to code, so be it. But enjoy the 24 hours, you do not get platforms like this every day.

After the Hackathon

  • Wrap up everything, pack the items and belongings, do not forget your chargers and peripherals.
  • Have one final meeting, plan out what you would like to do with the idea and the code / product built so far.
  • Divide the tasks for the future and decide timelines. If you leave here without a plan, and if you have not won the prize, it is highly likely that the idea will never be pursued further.
  • Know that what you are feeling, the mild body ache, sleepy red eyes, it is similar to a jet-lag and treat it as such, by sleeping only at your usual timing. Avoid taking an untimely nap in the day, set your routine back as soon as possible.
  • Write a blog. 😉

If there is something that should be added to the list to make it more usable, please suggest. See you at a hackathon some day.

Jetbrains messed up our license: Jetbrains still rocks!

Jetbrains messed up our license: Jetbrains still rocks!

Jetbrains messed up our license: Jetbrains still rocks!

It is story time today. We are a small startup, by small I mean like 4 people on the team and we established barely a couple months ago. It was time to start development and like all good Java developers depend on their IDE for their life, we did too. Too soon to go off-topic, but I wonder sometimes how large a program can I write without an IDE.

There is no better IDE for Java or Javascript than Intellij Idea from Jetbrains, and like all developers who know this, we went ahead and bought the Idea license. Lucky for us, being a startup, we were eligible for a 50% off offer. Jetbrains’s sales team was kind enough to approve it and we did get the license without much of a problem. My CTO asked me to get it set-up for myself, it was easy. There was a link in the email, I clicked, logged in and I got the license added in my Jetbrains account. It was almost smooth, except for a short to and fro on email to get the offer to reflect on the checkout page. All said and done, we loved the experience. Who would not love to get Idea at 50% off!??

So, done with the story? Why would I write it up if it was all so smooth? Read on..

A week went by without a problem and all of a sudden one morning my Idea closed on me complaining that I had no license! This was a shocker, we bought it, I had seen in it in my account and it was working for a week! I wondered if my CTO could have accidentally reallocated it, but of course he has better things to do than poke around in Jetbrains account configuration. I logged in to my account and turns out there was actually no license!

Since the CTO and I work in different time-zones, it was almost end of the day when we could chat and I could request him to check the matter. (A day saved by sublime-text.) Like I thought, he told me he had better things to do but we decided to have a look at the account anyway. Since it was a single link click for me to setup the account, he had not even created a Jetbrains account till then. We created the account and logged in, and were shocked to see some 31 licenses in our name. Something was certainly wrong.

Clicking through a couple of menus revealed that we were actually seeing the licenses/account of a different company! And our CTO, had become an admin for them. We had complete control over all the licenses, our as well as their licenses, and we could even decide who becomes an admin. We could remove their admin. While it was all fascinating (the devil!), we needed to know what happened to our license and we found it. This company’s admin had revoked my license and allocated to someone on their team! This company had a name similar to ours (Ours is one word, their was two), it was obvious that the person creating our license mistook us as them and instead of creating a new customer account amended theirs.

What do we do now? I contemplated our options and risks, contacting Jetbrains sale and support team and asking them to fix this was the best and the obvious option, but I had no idea how long it would take. What would AI do till then, being locked out of my own license, and when Idea keeps shutting down spontaneously. Can they even track it? Will they do it? Or would they ask us to buy a new one? There were a lot of unknowns, even when I knew Jetbrains would not leave us in the lurch. What if we wrote an email to this company’s admin and explain what has happened and request them to free up our license in good faith. But then they had their chance, they chose to to re-allocate a license they had not paid for to someone in their team, their admin would of course know this! They had their chance to see where the license came from, why it was allocated to someone outside, but they just revoked and used it, can we trust them to act on good faith? What if they just kicked our admin out, we would have no visibility into what was happening. Scary!

We quickly wrote an email to jetbrains, basically responded on the previous mail chain explaining this and requesting a resolution. Also attached a couple of screenshots showing what exactly had gone wrong, one showing the list of unrelated licenses and one showing our license being reallocated to someone else. Also tweated at Jetbrains to help us out, a good fellow working with Jetbrains responded and asked us to write to support email as well. We forwarded the email to support address and waited.

It was not long before we heard back from the sales team, some 4 hours or so. They quickly separated our company account, moved our license, assigned our admin and responded with a new link to claim license. We could now see a single un-allocated license in our account and allocate it. What they did great was that they also looped in this second company’s admin and wrote to them explaining the situation and offering a discount for one license. In my view, it was a good gesture at amending a mistake.

Mistakes happen, how you fix them is what decides if you retain your customers. And Jetbrains you certainly have retained us.

Cinnamon Crashed, would you like to restart?

Cinnamon Crashed, would you like to restart?

I have been a fan of the Cinnamon DE for years. I like the way it looks and stays out of my way when I am not admiring it and actually doing something useful! But it is somewhat buggy.

This is a quick post about the cinnamon crashes, basically a new reason for it to crash. I was faced with a common issue of cinnamon crashes, suggesting me to restart cinnamon, which when clicked yes resulted in another crash and popup.

Google searches resulted in many solutions, starting with updating cinnamon, resetting the config by deleting the .cinnamon and .local/share/cinnamon directories and verifying if the correct video driver is in use. There was nothing obvious in the syslog, or xsession errors. Nothing helped.

Tired, I reinstalled mint but issue persisted. This was rather peculiar. I mount my home separately, and that of course survives the installs and OSes. This was the first hint at the problem, issue was configuration of something, not necessarily of cinnamon. So I created a new user and tried to login with the user, and voila, cinnamon worked without a crash. So certainly the issue was config for my regular user.

I decided to go about removing related config folders, and the first ones I chose was the gtk-3.0, gtk-2.0 and cinnamon-session directory inside .config directory. And to my luck, cinnamon is working just fine since then.

Probably, I should spend some time to check what exactly from these config was the issue. But at least I now know one more reason why this error might occur and one more way to fix it. And now, you too..!