Live Templates have made my programming life a lot easier. There is a lot of boilerplate code that we type every single day. I like using Groovy script to build some powerful Scala live templates. Unfortunately the documentation for this is almost non existent. Oh well! I ended up looking at the IntelliJ Scala plugin’s source to find the available variables for live templates. You can see it here - IntelliJ live template variables ...
Disclaimer Do this at your own risk. I’m not responsible if your stuff breaks. You’ll be allowing Automator to control your computer. If you have weird automations you can potentially create security holes in your computer. Again, I’m in no way responsible if you do any of that. This is just a what I did to make something work. Let’s get to it then This morning I came across the duckyPad and almost made an impulsive buy. It looked really cool and had a ton of functionality, but I have the Moonlander which is a really nice keyboard and realized it could do what I wanted. ...
I primarily program in Scala. A few years ago, I got into Haskell programming when the director of engineering at the company that I worked for told me about it and let me set up a Haskell study group. It’s a language which you probably won’t use in real life unless you work for a company that can afford to play with languages like these. Haskell gave me the first taste of FP. My coding style entirely changed once I got into it and learned pure functional programming. ...
One of the things I strive for is to have full control over things that I can actually control. Life, emotions and even the code I write for a living. There will be things in life that are out of your control, so don’t worry about those. In the nine odd years of software engineering that I have done, I have learned to use feature toggles for code branch control. Yes, I’m talking about dynamically controlling which code gets executed in production using an incredibly simple technique. I have used this in a lot of personal projects, too. It works! ...
It started as a love-hate relationship. Today, after almost eight years of writing Scala code, I think I’m ready to say that it’s one of the best JVM languages. Coming from a Java background, my first taste of functional programming was in Haskell. Yup! That super scary language. It’s so concise that you barely have to write code :P. Back in the day I did some fairly hardcore Haskell programming and to this day I think everyone who wants to learn programming should learn Haskell just to understand the beauty of pure functional programming. The barrier to entry with Haskell is extremely high. It takes a while to become productive. ...
I personally believe in the boy scout rule for Engineers Always leave the code better than you found it If everyone said - the code was bad when I started working on it and there were no tests, so I am going to do my job of adding this new feature and I’ll just leave it the way it is - we will never have clean code. Imagine working on a new version of an existing class. You duplicate the class and notice that there were no tests for the previous version. You now have two choices: ...
This is a multipart series where I want to show you what tools I use every day and some of my favorite tricks. If you would like to know anything specific or if you know any tricks, do reach out to me. I feel developers need to get really good at using tools. I started off using Eclipse, but eventually got over it and started using Intellij IDEA. I have been a Vim guy and have not had a chance to learn Emacs. For a while I did use the Vim plugin in Intellij. It works great, but once you start using the in-built features of Intellij, you will see that it is a very powerful tool. ...
In software engineering every little thing matters. These are some of the principles I really like to follow - Write tests before writing code unless there is no logic in your code. If there is no test then there should be no code. If you write the test after you write the code, you most likely will be testing behavior and not what you intended to code Write clear, clean, and concise code that works no matter what Do not try to cure a global pandemic while writing a little feature. The business need for that will be part of a different story if it can be afforded Yes, O(n^2) vs O(n) vs O(log n) vs O(n log n) matters! It’s not enough if the code looks pretty Think about costs. If your beautiful code goes live and ends up wasting a million dollars for nothing, it’s not great Learn to use the powers of the IDE. It doesn’t cost $199 for nothing Always think about the code you are writing. At least twice. Maybe even three times if you can afford it. Check, double check and triple check if you can It’s essential to have graceful degradation. Broken software results in angry users Do not reinvent the wheel because you want to, but also do not add a huge library for 3 lines of logic The half - Be nice. It is important! (This is the half because it has nothing to do with the principles above. But it’s still important!)
TL;DR - Stick to something like the rule of three. Premature abstraction in any system is almost always going to be problematic, expensive and frustrating. Never add abstractions because you “might” need it in the future. Add it when you “really” need it Abstraction is a good way of hiding complexity. In your software development life, you probably have created well rounded abstractions that made your life easier. While abstractions make things cleaner and easier to work with, premature abstraction will have the opposite effect. ...
TL;DR - Try not to have logic in unit tests. The whole point of a unit test is to make sure some logic works TDD was something new to me about 8 years ago. I worked as a test automation engineer for a large corporation during my internship. My job was to automate integration tests. When I became a full time developer and starting writing production code, I learned about TDD. I realized that it’s one of the best tools that I had ever come across. Since then my mantra has been red-green-refactor. I have met newer engineers who ask the question - why test it if it works? ...