Finding a new software project is hard, whether it is for a company who must pay its employees every month, or for a freelancer who wants to ensure cash flow. During lean times, it is common to accept projects from any client just to stay afloat. But even in desperation, there are certain types of clients that you should avoid. Some of these clients are major red flags. Trust me, it’s better off to not work with these clients that to get trapped by them. Which types are they? Let’s see in this post. Continue reading “Choosing your clients: Whom not to choose”
Hello Internet. Today I am starting a series of posts that will explain how devices whisper to each other. Er.. what does that mean? Well, when devices are within a few millimetres to single digits of metres of each other, they don’t need to shout out, do they? That’s why we are learning about a few communication protocols that are used when devices are near each other.
“But isn’t it better that devices are able to communicate from really far away? What’s the point if they just communicate when really close?” Bear with me, as I am going to give you some good reasons for why devices should communicate only when close to each other. Continue reading “When devices whisper to each other – Part 1: Intro”
A couple of years ago, I read the book The Best Interface Is No Interface, by a man who calls himself Golden Krishna. Mr Krishna is a UI/UX specialist who consults several big companies on how to design their UI. While most UI/UX specialists get paid based on the number of screens / UI components they design, Golden Krishna gets paid based on how many UI components he eliminates from an application. Sounds contradictory, but true. Why?
This is because the golden boy of UI is eliminating unnecessary work and saving development time for companies. His consult on making less UI and screens is taken seriously and as a result companies make small, light-weight and easy to use applications. Continue reading “When no UI is the best UI”
Did you read the title of the post correctly? Am I, a software engineer, really encouraging you to reject writing software solutions? Yes indeed I am. There are times in your career when you’ll need to evaluate if a particular problem really requires writing a new piece of software. Sometimes, you’ll find that a NO is the best answer for everyone. Continue reading “When to reject creating software solutions”
You have probably seen ways in which the physical world represents digital data in print. The one you are most familiar with is perhaps bar codes. You see them on products at a shopping mall. The checkout counter scans them and fetches the information about the product from a database. Even books have their ISBN codes printed in a bar code.
Over the last decade, another technology named QR or Quick Response code has gained popularity. While traditional bar codes are 1-dimensional and can represent at best between 16 – 20 characters of data, QR falls under a group of data encoding technology called the ‘data-matrix code’ or colloquially, ‘2-dimensional bar codes’. QR codes were pioneered by the Japanese company, Denso wave.
QR codes are capable of holding 7089 characters of data. You can see QR codes all over the Internet, on packaging, on information booklets and even on branding boards at shops. They usually serve as a way to encode URLs so that the user can get further information about a product or an organisation. But URLs are not the only thing possible inside a QR code. Let’s see how they work. Continue reading “How QR codes work”
As one of the latest catchwords in the world of software, DevOps is a term that has been growing in popularity over the last decade. Is it yet another meaningless jargon which will fade away when the fashion wears off (Blu Ray discs, are you listening?!). Or is it something really useful, practical, helpful and here to stay for generations to come?
To understand what DevOps is, how it works and how it helps the people who use it, we sat down with software developer Dave and operations manager Oprah to understand how they use DevOps in their company, FutureSoft Solutions. Continue reading “Understanding DevOps: An interview with two practitioners”
Software projects are complex. Often the goal of an application looks simple, but as time progresses, the participants realise how complex the it actually is. Usually they fail to consider every type of input and the corresponding output. Fringe cases are often ignored and suddenly need to be accounted for. The most overlooked flaw is a lack of communication between the one who wants to use the software and the one who builds it. Requirements are not fully discussed and expectations are not fully set.
Most projects are difficult because they are not started the right way. The project starts in a direction that has already drifted from the desired outcome. It continues to drift until a lot of changes or even a ‘scrap and rewrite’ are needed to bring it back to course at a much later stage. In this post, I would like to discuss the points which should be taken care of so that you start a software project the right way. Continue reading “Starting a software project on the right foot”
Software engineers switch between two modes: painful perfectionists and band-aid stickers. During the start of a project, software engineers discuss things to painful detail on whiteboards, Post-It notes, restaurant napkins and even glass doors. This eats away precious time that could have been spent on actual development. But as the deadline looms, the whiteboards and glass doors are rubbed, Post-It notes are torn apart and restaurant napkins are trashed. The plans are chucked in favour of anything that makes the application work.
Often, the released solution has plenty of duct tape code that holds the functionality together. After all the over-planning, duct-tape coding is the only thing possible in the limited time that the programmers leave for themselves. Software teams hardly release anything during the early phase of a software project as everything is put in meticulous detail on paper only. But as the deadline approaches, frenetic releases are made everyday or even every few hours, causing confusion among the developers, project managers, testing teams and the clients.
The world of software and information technology throws up jargon at an explosive rate today. It is hard to keep up with them and even harder to understand what they mean. One such term is SaaS or Software as a Service. Let me explain what it means and how it is important to you.
What is SaaS?
SaaS refers to a software that MANDATORILY has the following properties.
- The core of the service runs over the Internet on a server, while the user works with a bare-bones tool on his/her device.
- Usually nothing is installed on the user’s device and a browser is used to connect to the service. Even if something needs to be installed, it is just a small app with a user interface and a set of functions that connect to the Internet to exchange data with the service’s server. No service functionality resides inside the app.
- No storage happens on the user’s device. All of the user’s data is stored on the server securely.
- The user needs to connect to the Internet and login to an account in order to use the service and access his/her data.
- Due to the service being on the Internet, a user can access his/her data from any device from any location, be it on a smartphone from a car seat, on the home desktop computer or on a laptop from a resort.
- As a result, changes made from one device are almost immediately available on another device.
- Functionality can be extended on a daily basis because all the functional code is on the server. The user doesn’t have to install a new version on his/her device. In case of a web application via a browser, even the UI can be updated frequently without the user having to install anything.
This is contrast to a traditional desktop software application, where a huge software application with UI and all the functionality is installed on the device’s storage, all the files are stored locally on the device’s storage device and the user needs to remember to copy the files to a portable storage unit such as a thumb drive in order to transfer them from one device to another. Changes also need to be synced among devices every time. Changes to functionality are released as a new version of the application and they too need to be installed on the server.
Apart from the above features which are mandatory, Saas MAY provide some of the following features
- Limited offline access to use the service when Internet is down.
- The ability to download files to local storage.
- The ability to connect one SaaS to another in order to use the features / content of one in another. E.g. Pixlr can use your Google Drive as storage.
- Ability to share your files with other accounts as read-only or read/write.
Examples of Saas and equivalent desktop applications
Real examples of Saas are as follows.
|Microsoft Word||Google Docs|
|Files and directories||Dropbox|
Where SaaS fails
- The biggest failure of SaaS is when going for long periods of time without Internet. While some SaaSes allow you to edit your content offline, your content will not be synced to the server. So if another person makes changes to the same files from another device, there will be conflicts.
- An insecurely set up SaaS can cause a risk where contents can be snooped and even downloaded by unauthorised persons.
- All the data is in the hands of the company providing the SaaS and not in your control. A change of policy or an infrastructure collapse can lead to loss of your data.
What you need to build your own SaaS
If you are a company who wants to build your own SaaS, the following should be your technical know-how. There are further requirements such as strong policies and legal agreements which are beyond the scope of this post.
- Setting up your own server either in physical form or on a cloud service such as Linode, Rackspace, Amazon Web Services or Google Cloud Compute.
- Complete knowledge of HTTP protocol. The app on the device and the server communicate using HTTP.
- Securing your HTTP communications using HTTPS.
- Programming on the server side using one of NodeJS / Python / Java / Ruby / PHP / .NET.
- Using server side file system and databases for data storage.
- Using OAuth to validate users who log in and to reject users who are either no signed in or are using invalid credentials.
- Using OAuth to allow other apps and users to access a given user’s data.
- If you are making platform-specific apps, then here are your requirements.
- Java / Kotlin programming for Android
- Swift programming for iOS
- .NET programming for Windows
- Cocoa application programming for MacOS.
- QT / GNOME using C++ or Python for Linux.
- Usage of Continuous Integration and Continuous Delivery to roll out new versions.
- System administration for the following requirements.
- Monitoring the server to make sure that things run smoothly.
- Frequent backing up so that data can be recovered.
Being the trendsetter of the last decade, SaaS is now commonplace since 2010 or so, when rich web applications, Android and iOS took the world by storm. There was a need to access apps and their data from anywhere to which SaaS provides the solution. And that need and the success of SaaS is not going away anytime soon.
What do you do when your application needs to store something? Are you the type of developer or company that habitually jumps to create a database everytime you see that an application needs to store something permanently? Worse, are you the type of programmer who stores binary things like images, music, videos and ‘what not’ inside databases too?
On the other hand, are you so petrified of and averse to databases that you store everything in Excel, comma seperated or JSON files?
In this post, I put forth some rules I use to decide what goes into databases and for what type of data you should consider a different data storage.