A few months ago, I watched the documentary “Get Involved!” by Rob Conery and Scott Hanselman. It is available as a free video course from Pluralsight. In the feature, Rob and Scott provide advice on becoming a “social programmer” in order to enhance one’s career prospects.
Below are my thoughts on the different channels they talk about.
This is definitely my favorite medium. In my opinion, blogging helps me improve my writing while also providing a means to archive the knowledge that I am acquiring on a daily basis. On the other hand, it is not without challenges. I find it difficult to come up with good topics to blog about. Additionally, I often feel self-conscious about my writing style and the level of my knowledge of the topic I am writing about.
There is an excellent walk through of this service in the documentary. I must admit that I stayed away from Twitter till recently. I was not sure that I wanted to deal with the flood of information given that I can barely keep up with my email. Also, the ephemeral nature of the medium makes it a very synchronous activity drawing away focus from anything else I may have going on. I finally signed up but I am not very active yet.
This is probably the best option to showcase my programming abilities. I can help other open source projects or publish my own projects. While I have some work uploaded, I plan to be more active in the future.
I use it a lot but have no interest in being a contributor.
This includes the big conferences as well as regional user groups. As a regular participant in several local meetups, I have been getting value from networking and learning about new things. However, I realize that the real key to building authority and reputation is by being a presenter. I plan to do that soon, starting with lightning talks.
Others Not Mentioned
- Slack: The local developer community is very active and I contribute where I can.
- LinkedIn: While I have been sharing short blurbs and links, I have not yet utilized the option to publish long form posts.
- Medium: This is definitely the blogging platform of choice at the moment. I am staying away just because I don’t have the time to create separate unique content for it.
- Book: This is one of the highest forms of achievement especially if published traditionally. I do dream of doing it one day.
At this point in my career, my primary focus is on learning. However I do realize that I need to build and maintain a public profile as a programmer and that process can take a while. So I have been allocating some of my precious time to blogging, putting up code on GitHub and attending local Meetups of interest whenever I can.
Before I started my journey to become a Software Engineer, I did not think about software security much beyond installing a good anti-malware product on individual computers and configuring the wireless network with the most advanced security options. As an ordinary user, I just had to use strong and unique passwords for each of my online accounts.
Of course, now I realize that there is a lot more to it all than just following the above guidelines. I like to classify the topic of software security into three areas.
- Network security: Set of measures to protect the underlying network, computing and data resources from unauthorized access and service disruption.
- Application security: The entire gamut of technical concerns such as SQL injection, buffer overflow to permissions of files deployed in production.
- Logical security: The business rules controlling user role based access to application functions and data.
I was recently able to dive deeper into the application security aspect of software security through a few different means.
At work, I freed up a little bit of time to go back and complete a couple of online training courses that I had scheduled a while ago. The first course was a comprehensive introduction to application security for a Java developer. It covered a range of topics from the OWASP Top 10 and PCI DSS to cryptography and vulnerabilities within the Java language. The second course was specifically about web application security concepts. This is the stuff developers usually think of when hearing the term “software security”.
Both the courses helped me get a better grasp of the fundamentals of software security. I began to see how I could incorporate the lessons from them into my own development practices.
Then, I had the opportunity to attend two Meetups on associated topics within a couple of weeks of each other. I gained a further understanding of the practical aspects of software security from these sessions. I decided to document my takeaways from them in this post.
- The biggest security threats originate from inside the organization’s network, not from outside. Most of the damage occurs when people fall victim to phishing or social engineering attacks.
- Default configurations of many Operating Systems and Networking Software used in companies are insecure.
- Even if the configurations are secured, patches or upgrades to the components above may revert them back to insecure settings.
- Once inside a network, malicious hackers can use powerful command line tools – that are openly available – to scan other connected resources and compromise them.
- Security cannot be bolted on at the end of the development cycle. It needs to be incorporated into every step of the process.
- Perform threat modeling and risk assessment during the initial stages of a project.
- Build security related deliverables into the product backlog.
- Some of the risk mitigation measures may have to be deferred to the clients using the product.
- Code signing and certificate management get really complicated in CI environments.
- Keep IOT/embedded devices off the internet.
- Both the JDK and popular third party libraries have vulnerabilities. Those might not always get fixed immediately after they are discovered.
Overall, I walked away with a great appreciation for the importance of software security and the amount of responsibility developers have to ensure that the software they develop is secure.
It seems that almost everyone is using RESTful APIs everywhere. A very common question that comes up is which of the two HTTP methods PUT and POST should be used in a particular situation. In this post, I will describe my understanding of the difference between the two methods.
The PUT method
- It can be used to create or update resources.
- It is idempotent. This means that multiple invocations of this HTTP method will produce the same result. In other words, there are no side effects.
- It needs an exact URI location. This can be a problem if the server is responsible for generating unique resource identifiers.
The POST method
- It can be use to only create resources.
- It is not idempotent.
- It does not expect an URI to contain a resource identifier.
- The server should respond with a location header element.
- Returning the newly created resource object is optional.
Of course, all this looks great in theory. However, I have run into scenarios that did not fit either method perfectly. And sometimes, technical considerations have forced me to go against these guidelines. But in the majority of the cases, I have found that the above rules work well for me.
As I was trying to solve part 2 of the Day 6 problem in the Advent of Code 2015 challenge using Java 8, I ran into a curious problem. I had defined functions as follows for the various operations.
public static Function<Integer, Integer> turnUp = i -> i++;
However, the solution from my program did not match the official answer. At first glance, I could not figure out the cause for the discrepancy. But after thinking about it for a while, I had a “a-ha moment” and wondered if the postfix version of the increment operation was the source of my issue. So I modified the functions to a prefix version as follows.
public static Function<Integer, Integer> turnUp = i -> ++i;
Sure enough, the solution from my program matched the answer after this change.
The lesson here is that if you are relying on an implicit return from your lambda function, then you should use the prefix version of unary operations. That will ensure that the operation is performed before rather than after the return action.
Even though nowadays it is generally expected that developers would always write unit tests, I have run into quite a few of them who loathe doing that. In fact if it weren’t for test coverage gates in the code check-in process, they would completely skip that step and keep coding new features instead. But forcing developers to meet a certain testing metric does not always produce the desired results. You can end up with a bunch of useless test cases that were written specifically to meet the minimum required coverage threshold.
Now I will admit that I myself have sometimes wondered what the point of unit tests was. Why should I have to write a completely separate set of methods to prove that the code I wrote in the main source directory actually works? Keep in mind that when done the right way, the amount of code in the unit tests is often greater than the amount of code that is being tested. It seems to be a terrible waste of valuable developer time and effort.
In my mind, there are two convincing reasons why unit tests make a lot of sense.
- When I approach the problem with a testing mindset, I discover facets that are not readily apparent when I am only thinking about the solution. For example, writing tests leads me to address concerns such as boundary conditions and exception scenarios. Of course, test first development is a natural extension of this line of reasoning and has proven to produce better designs and fewer bugs in new code.
- Value is also realized when someone (even if it is me) revisits the main code to either enhance its capabilities or fix defects. The developer can confidently make changes knowing that the existing unit tests would protect him from accidentally breaking current functionality. That safety net pays for itself as long as the code lives.
However, to truly benefit from the above, the developer should put in the effort to write good unit tests. This does take some learning and experience. Additionally, the developer should follow best practices to ensure the test code is of the highest quality. This is especially important because there are no unit tests to back up the original unit tests.