Month: July 2019

Posted on

Development Environments

Workbench

As a developer, it’s a great time to be alive. We have countless options for development languages and frameworks. But, sadly, many of them leave much to be desired in terms of tools and environments.

The Model Environment

As a veteran Java developer, I’ve been spoiled with excellent tools. We have numerous IDEs including Eclipse, NetBeans, and IntelliJ. Everyone has their preference, but all three are excellent. Likewise, we have numerous build and dependency management packages such as Maven and Gradle. We have test frameworks, automation frameworks, debuggers, profilers, and anything else you could want to engineer even the most complex of application. In short, Java provides the best development environment there is. Seriously. Few languages have IDEs as good as what Java has. Even fewer have tools that can complete with Maven or Gradle.

When Will Other Languages Catch Up?

I continue to see how Python is displacing other languages. But when will it catch up to Java in terms of development environment? Are there any IDEs that complete with Eclipse for Python? (NOTE: Eclipse can actually be used for Python, but it always seemed to me more of a hack than a real Python IDE) How about debuggers? Go ahead and try debugging Python or JavaScript code and you’ll quickly see how far behind Java they are. Not to mention dealing with libraries and environments!

A Call to Action

As we continue to shift to newer languages, I’m concerned that the next generation of developers will actually have a more difficult time than we do today. Why, as a development community, are we only focused on creating new languages but not on creating solid environments? How are Go, Python, Rust, and the myriad of other languages ever supposed to achieve the same widespread adoption of Java if we never had the rest of the tools we need to get the job done? I want to enjoy the benefits of some of the newer languages to come along. But, until they can complete with Java, I’m unable to stake the success of my customers on them.

Posted on

Fit for Sale

Sales

As an app developer, I am often approached by friends and acquaintances with “great” app ideas. They believe their idea is worth millions and that I should drop everything and develop their app. Businesses too fall prey to the idea that “I need an app“. Either way, it’s imperative that adequate market research be performed prior to developing any piece of software. 

A Great Idea

A few years ago, I was approached by an individual who had a “great idea” for a software application that was going to revolutionize the industry. He had some startup money to develop the application, and was in a hurry to get started. He contacted me to write him a mobile application, cloud-based management system, and REST services for integration points. It was an ambitious project for the client, and I was excited to start developing. He provided the requirements to me, and I wrote the software. I provided feedback to improve the application, but it was ultimately the customer’s decision what he wanted to include or not include.

Poor Market Research

Unfortunately, as the project moved forward, I learned that the client had very little money for development. None-the-less, we worked to create a working product which we achieved on his budget. But, as he would learn during the next month, he was creating an application that nobody actually wanted. Not only did his application lack features that would be necessary for adoption, it served only a very small niche market. The customer assumed he knew what people wanted, and had never bothered to reach out to any prospective clients for feedback.

Consequences

Due to the customer’s poor market research, he was unable to find clients interested in his software application. Months went by with very few interested parties, and nobody ultimately purchased the software service. Consequently, the customer blamed me for writing an application that nobody wanted. He even fought me on payment because he was unable to make his money back through sales.

Lessons Learned

There are several important lessons to be learned from this experience. First, if you’re paying someone to write you software or create any other work for you, make sure it’s worth the cost. It’s your job as the customer to know what you are purchasing and to ensure that it will meet your business objectives. As a software consulting firm, I can provide you with information and develop software. However, I can’t tell you wether or not your application will be a success. Second, market research is of paramount importance for any project. If you don’t know the target market, the demographics, the estimated number of consumers, and other key data; you can’t determine financial viability of the project. Before you go into any project, do your part first and ensure that the work you are paying for will take you where you’re trying to go!

Posted on

Debugging & Maintenance

Debugging

Long after the initial fun of developing an application comes years of debugging and maintenance. Yet, many languages and developers fail to make choices that will ensure that future maintenance will be possible. Then, when problems occur, substantial time and effort is spent trying to resolve the issue.

Current Trends

It seems that right now, a growing number of developers and development teams are transitioning to languages like Python and Javascript. Both of these languages can do great things. Unfortunately, they both suffer from the same problem – they are incredibly hard to debug and maintain. Why is that? Python and Javascript are both weakly typed scripting languages. What does that mean? In short, it means that the programmer can be lazy about how they define things and let the computer do all the work. Unfortunately, it also means an increased risk of runtime errors and greater difficulty in finding problems.

Magic Frameworks

This is exacerbated by magic frameworks. Everyone loves Ruby on Rails and Django. But both become a nightmare to debug very quickly. Need to change something from the framework? Great – your hack will be the source of nightmares when you leave. While these frameworks may simplify our lives in the short term by providing a quicker time-to-market, in the long-term they are more difficult to maintain.

How Can We Fix This?

Unfortunately, I have rarely seen well documented Python or JavaScript code. Typically, users write code and forget about it. Online videos and tutorials rarely stress the importance of comments and documentation. Thus, we end up with fragile code nobody understands. As a developer community, we need to do a better job of passing on our knowledge of code to the next developer. This means comments, readme files, and other documentation. If you write software using weakly-typed scripting languages, you owe it to those who will debug your code later to put in the extra effort!

Posted on

Classic Hacking

Security

I’ve been involved with technology since the mid 90’s. During the late 90’s, I worked on Unix systems. It was those experiences that lead me to love Linux, taught me to program in C, and helped me learn to automate tasks using various scripting languages. But the 90’s were a much different time for security. Nobody really worried much about hackers or social engineering. And now, over 20 years later, I see people in the workforce that have been robbed of some of the fun I had in the past due to increased security on machines. Of course, increased security is good, I’m not going to argue otherwise. But it has also made a lot of the ‘fun’ from the past no longer possible.

Remote Display

When I was working on old Unix systems, one of my favorite hacks was to set my display to another computer. Since Unix display works as a client/server model, you can actually set your app to appear on any computer monitor you want. So, it was common where I worked to find the most horrible graphic you could and display it on someone else’s machine. Always a good laugh. Other tricks would allow you to play audio on their speakers (great when the individual has fallen asleep at their desk) or turn their keyboard buttons on and off.

Password Files

Long before the /etc/shadow file, passwords were stored in the /etc/password file. And, since the file was readable by anyone, you could easily grab the entire password list and run it through a tool like John the Ripper. Even more fun, commands like ‘ypcat’ would allow you to get the passwords of all users on the network even if they weren’t on the local machine.

Email Overflow

My sister’s first experience with the internet was through a device called “WebTV”. This device was a small terminal that would turn your TV into an internet terminal. It was a cheap, easy alternative to a computer. It also suffered from a pretty simple flaw – you could only have a limited number of emails. (200, I believe.) I found an unsecured email relay – pretty common in the 90’s – and spammed my sister with enough messages to flush out all her email. As you might guess, she was mad.

A New World

How things have changed. Unsecured email servers are much more difficult to find, and Unix is now much harder to hack out-of-the-box. While most of the hacks of twenty years ago were mischievous in nature, today’s hackers are far more sinister. And, thankfully, the world has adapted to become a safer place. Nonetheless, I still look back to the simpler days of computing and the fun we had.

Proudly powered by WordPress