Stored Procedures

Of all the technologies out there today, databases are among the most important. Boring as the idea may be, the storage of data drives the information age. Indeed, databases are as ubiquitious as the webpage itself. Order information from Amazon, posts on Facebook, content from WordPress sites – all stored in databases. Because of this, database management is hugely important – so much so that people work full time jobs in database management.

One of the technologies that databases provide is what’s called a stored procedure. Stored procedures are code that runs on the database to aggregate data, calculate information, perform business logic, etc. Many people love to put all kinds of logic in stored procedures so that they don’t have to rewrite the business login on multiple platforms. And, indeed, they can be useful at times. However, during my career I have grown to despise stored procedures.  Why? While stored procedures give the promise of simplifying logic on your application code, what they also do is increase the complexity of deployment and circumvent source control systems.

Since stored procedures are external to the application code, deploying an app is more complicated than simply placing an application on a user’s computer. Now, you have to first upgrade the database functions and then upgrade the application. No big deal, of course, since applications often require database updates. However, unlike table structure, stored procedures are more likely to change frequently in order to fix or tweak the logic. Thus, you end up with different versions of the stored procedure on different databases. Now, the same application will behave differently when running against a different database. This becomes a support nightmare. Is the issue a software bug, or is it a problem with the stored procedure? This leads directly to the second problem – no source control. Traditional application code is managed by source control systems. Every change is logged, and the history of the project can be observed for the entire lifetime of the project. Stored procedures are code applied directly to the database, and tweaks are often not entered in source control. Thus, you can’t easily revert back to a previous version since you have no record of it. This lack of history means we can’t see what other developers did and you have no idea why something was changed.

In my opinion, stored procedures often become the wild west of software development. For all the value they can bring, what I’ve seen them bring is additional bugs and confusion to the software process. When I work on projects, I will fight against the use of stored procedures unless an incredibly strong argument can be provided for their inclusion.

REST Tools

REST services are everywhere now. Long gone are the days of RPC and other horrible tools for running functions on a remote machine. This is great news for developers as older frameworks were very cumbersome and far less useful than REST services. What makes REST even more important is that they are used along with JSON to enable all kinds of slick functionality on the internet. Indeed, countless web applications and mobile applications now use JSON-based REST services. And just as there are numerous applications using JSON and REST, there are countless ways you can test REST services and create mockup services. But not all tools are created equal – particular for lightweight, simple testing. For example, a colleague recently said he was using Java and JAX-RS to mockup REST services. Certainly you can do that, but the amount of code you need to write and the frameworks required make it anything but simple. What tools do I use for REST testing? I like to use Python and Flask for mocking up REST services. For example, I can create a simple REST service in Python to return the sine of a number with the following snippet of code:

from flask import Flask
from flask import jsonify
import math

app = Flask(__name__)

@app.route('/sin/<num>',methods=['GET'])
def trig_sin(num):
  rad = float(num) * (math.pi / 180)
  sin = math.sin(rad)
  dict = {'input':num,'sin':str(sin)}
  return jsonify(dict);

if __name__ == '__main__':
  app.run(debug=True)

This is a full service, not a mockup. A mockup would be even simpler – just create the route and return the JSON you want. Nothing could be simpler for mocking a service.

For testing services, I use Visual Studio Code and the REST plugin by Huachao Mao. To test the above service, I can enter the snippet below into a file with a .http extension, and the REST plugin will create a button for me to call the service.

###
GET http://127.0.0.1:5000/sin/60 HTTP/1.1

I can create countless test calls as well as supply headers and JSON POST data. Even better, the .http document creates a documentation that is concise, clear to understand for anybody who develops REST services, and can be interacted with to see the output of the service. These two tools are my default choice for any type of REST testing.

The Importance of Source Control

While professional programmers always submit their code to a source control system such as git, svn, or tfs; most hobbyists and learners do not. This is a huge mistake. I always encourage people to check their code into a source control system. But why? For the learner or hobbyist, there are a few big reasons to do so. First, as developers we often realize we’ve solved the exact same problem before. But when? Where? How? Having a repository of your own demo code gives you reference material for future projects all neatly stored away. Second, as that repository grows, and you mature as a developer, you may want to pursue a job in software engineering. A growing number of companies ask to see your GitHub account – this is a great way for an organization to see what your code really looks like. Start building that portfolio of code now! Third, source control serves as a backup for your code. When the project you spent months working on is destroyed because of a hard drive error, what do you do? If you have your code on committed to a source control system, you download your most recent copy and move on. Very little is lost. There are countless other benefits to source control, but these are some of the simplest benefits an up-and-coming developer can realize quickly. If you don’t have an account, go to BitBucket.org or GitHub.com and set one up!

Cryptocurrencies and Blockchain 

With the price of a bitcoin surpassing $10,000 and the recent craze around cryptocurrencies, developing an understanding of what the technology behind these cryptocurrencies actually does, as well as what can become of these technologies going forward seems worthwhile.  Before we can begin to truly understand what cryptocurrencies like Bitcoin and Ethereum are, we need to look at how blockchain technologies work and why these technologies hold immense value for people around the globe.

The technology behind the blockchain is fairly simple conceptually speaking, though incredibly innovative nonetheless.  The fundamental issue that prevented digital currency from taking off for so long was the ability for any person to make duplicate transactions.  For instance, when a person sends an email, they are never actually sending the original message but rather a copy, so if two people claimed to own the same digital currency, there would be no way to prove the actual owner without having a fine-tuned system in place.  A blockchain solves this problem by validating transactions through solving cryptographic riddles and maintaining a universal record of all transactions, an ongoing process carried out by a decentralized network of computers around the world.  These miners are rewarded for their work through miner fees and their ability to unlock and release new cryptocurrency into existence.

In the United States, we believe in the value of the dollar.  Millions of Americans work hard at their jobs inputting their time, energy, and resources on a regular basis.  This results in them earning a paycheck, often directly to their bank accounts.  With this money, people make transactions based on trust:  trust that their debit or credit cards will work, trust that they can access and spend their money, and trust that this money will not be tampered with at any point between sending and receiving payment.  But this trust-based service comes at a cost, around 3% of our transaction fees to be exact.  The blockchain reduces the need for a middle man and enables direct peer-to-peer transactions, minimizing the potential for tampering and corruption along the way at a lower cost, roughly 0.1% or so, which pays the miner fees and gives people an incentive to keep the decentralized network active and growing.

Looking specifically at a cryptocurrency, Bitcoin began back in 2009, and its blockchain has been recording and validating transactions ever since.  Unlike the US dollar, there is a finite supply of bitcoins that can ever be created, capping out around 21 million.  Currently, less than 17 million of these exist, and as time passes each bitcoin becomes more difficult to mine.  This element of scarcity is appealing from an investment standpoint, because as demand increases the price does as well.  Investing in cryptocurrency today does not come without considerable risk though, considering the market is very volatile.  In the grand scheme of things, these cryptocurrencies are still very young, meaning that people base much of the value on the integrity of the system, also considering what the future of these cryptocurrencies might hold.

iOS Development Horrors

This past week, a client asked me to write a mobile application for both iOS and Android. I don’t do much native iOS development, so my first choice is typically Cordova – particularly for simple applications that don’t require native support. As I started setting up my client’s new project, I decided to go back and update some of my old iOS apps. They don’t get near the attention my Android apps do, and this seemed as good a time as any to do some needed updates.  I have three iOS apps on the iTunes store – one is native and the other two are Cordova. I got everything setup for the Cordova apps, then went into Xcode to build the final release. Xcode started by telling me  my icon resources were invalid. No further information was given – just that they were invalid. It appears that Cordova doesn’t generate all the right icon sizes, so I had to generate my own. This is great because you need 30 – that’s right, 30 – icons for an iOS app. You need to generate all thirty icons and then assign them to their associated spot in a giant tree of devices. Of course, the spots where you place the icons don’t say anything useful like 60px – no, it says 20px 3X – or 57px 2x. So, first I generate the maddening amount of icons and then I have to do math to figure out where to put each icon. Next, I try to change the splash screen from the Cordova icon to my company logo. Of course, Xcode provides even less information for that. Simply a heading like “iPhone 6s Landscape”. The only way to get any help is to stick an image with the wrong size in the spot and see what the warning message says – which includes the desired dimensions. This process took an hour just to get the splash screen and icons working. Why? Every single icon is square. Can’t I just provide the highest resolution and have Xcode figure out the rest? For my splash screen, can’t we find a more elegant solution? For instance, I provide an image and tell you the sizes to use it for – just crop, I don’t care. I would need to provide a few different images to account for smaller sizes, but it should be an hour just to get such trivial work done. After that, I tried to build but received errors about my signing certificate – so I had to redownload and jump through some more hoops. Finally, I uploaded to Apple only to receive an error message that my build included images with an alpha channel. (It’s 2017, Apple, why can’t you support transparent images yet?) Almost there…. I add my text to describe what I’ve changed, and hit submit. I get an error on my text saying there is something wrong with my internationalization. Another half hour of trying to figure out why my text is wrong, and then a trip to Google only  to find out that the problem was that I didn’t have enough screenshots. More image fun – I need to post pictures for 5″ devices. I’m not exactly sure what devices are 5″, so I have to try various emulator settings until I figure it out. And, finally, my app is off to Apple for approval. Then, on to the second Cordova app for more fun!

After that, I move on to my native app. Already knowing what to expect, I gather the necessary images and prepare for the new build. But wait – my storyboard is all messed up. Apparently, during one of the more recent Xcode updates, they changed everything. No problem – I’ll go into their interface builder and fix it. Or not. The interface builder is so slow it’s unusable. Back to Google, I find everyone complaining that Xcode 9’s interface builder is horrible. Their experiences mirror mine – minor changes taking 10 seconds to be reflected, spinning beach ball, CPU pegged, etc. I have an utterly trivial interface – just a series of labels and text inputs for logging ham radio contacts. But after an hour, I was no further then when I started. Apparently, I’ll be waiting till the next version of Xcode to fix my app since the current version of Xcode is unusable.

And that brings me to my real frustration. During my career, I’ve used countless development environments – everything from Delphi to Borland to Visual Studio to Eclipse to Lazarus. And in all my years, I have never seen an IDE as bad as Xcode. Apple – it’s time to move into the 21st century and create an IDE that’s as amazing as your laptops. Stop forcing us to use an environment that should have been abandoned decades ago.

React Native

Most of my mobile development is in creating native Android solutions. However, I sometimes need to create iOS apps as well. I have done native iOS development, but if I need to have a cross platform solution, it obviously requires twice the effort (and cost) to create native apps for both versions. And, when you’re done, you have to maintain two different apps as well as deal with bugs on two different versions. Throughout the years, a variety of solutions have been made available – and with the continued growth in the mobile market, I expect to see more tools available in the future.

During the past week, a colleague recommended that I look at React Native for creating cross-platform apps. Then, yesterday, a customer asked me to create a mobile app for them on both iOS and Android. So, I decided to investigate React Native.  The website for React Native talks about how you can use JavaScript to create native apps – not hybrid web apps, but real native apps. That sounded very exciting! I installed their framework without much trouble and began tinkering around. While I am not a fan of JavaScript for larger projects, I realize that it has become the language of choice for a growing number of tools because of it’s widespread acceptance. I used Visual Studio Code as my IDE, connected my demo app to a REST service, and had a trivial mobile application running in minutes. The most awesome part of React Native development is that the test app on your phone is always in sync with the changes you make on your development computer – without a USB cable – so long as you are on the same WiFi network. Now, the next step – create an actual Android APK to push to HockeyApp for distribution to my software testers. Wait… there is no easy way to do this. I have to ‘eject’ my project from React Native – a process which I am warned is not reversible – and then use native tools to build the APK. So, I can start the project in React Native, but then have to export the project to a native form to actually deploy. This was a show stopper to me – I don’t want to have to export to native tools as that invalidates the entire purpose of a cross-platform project to me. I dug through the documentation trying to see if I was missing something, and others had asked the same question. As I dug further, I saw numerous users complaining about how out-of-date the documentation was. That concerns me – if I want to learn the framework, I need to be able to rely on the documentation. Having found no way to easily create an APK, I gave up.

In the end, for this project, I think I will stick with Cordova. It may not be as exciting as React Native, but I can chose whatever frameworks I want to use – be it a high-tech Angular app or a simple HTML5/JavaScript application. The tools work well, and – maybe one of the most important things to me – the project can be maintained by anyone who knows HTML5.

 

 

Tech Toys

I play around with a lot of technologies. I think it’s important for anyone in the technology field to explore new technologies. In order to provide the best solutions, I have to know what tools are available. Some good technologies don’t receive much buzz, others don’t receive enough. So, what technologies am I playing with right now? Recently, I started looking at Processing and OpenCV. This technology has been around for awhile, but I’ve never had the pleasure of playing with it. Processing uses Java, but programs almost like Unity or Arduino with a call to set everything up and a loop function to execute the code. what makes processing so great is how much it simplifies graphical programming. Another exciting technology is Johnny-Five. This framework, named after the famous robot from Short Circuit, is intended to create a unified framework for programming a variety of hardware boards for robotics. It uses JavaScript, and an event-driven model which greatly simplifies robotics for those unskilled in C++. What’s also awesome about Johnny-Five is that it runs on your computer instead of directly on the hardware. While this could be viewed as a con – since you need a computer to run project – it also means you can integrate functionality from the computer into the project. Your hardware project can now function as an I/O device for something much larger. And, with huge number of small computers available now (such as the Raspberry Pi), you can still create small portable projects. The next technology on my list right now is .NET Core 2.0. As a Mac/Linux user, I avoid Microsoft-only technologies. But .NET Core 2.0 now runs cross platform. And, even more exciting, it’s actually pretty good. I have been very excited with the ease that i can develop web applications with their MVC framework and even happier about how easy their Entity Framework is for interacting with databases. Lastly, I’ve been tinkering with Angular. I’ve avoided most of the JavaScript frameworks over the years. I typically use JSF with the occasional jQuery when needed. But, the buzz around Angular is too great, too many jobs want this skill. So, I’ve started tinkering around with it. Looks great for some applications, but I’d rather stick to Java for larger applications. There are lots of other technologies out there I’d like to explore – if only there were more hours in the day.

Multi-Factor Authentication

Yesterday, after writing about the pain of added security when dealing with baking websites, I upgraded my Mac to High Sierra. When the upgrade was finished, my Mac asked me to enter the authentication code sent to another Mac machine I own. Fortunately, I had my another machine nearby, so I entered the code. Then, it asked me what the password was to unlock the other machine. That sounded strange to me, but my Apple keychain would have that password. Then, the final hurdle was to change my password since it was the same as my iCould password – and Apple doesn’t allow that anymore. Wow. Apple must think I’m storing nuclear launch codes on my laptop. Then, I went downstairs to run some updates on my wife’s Mac. Not an upgrade to High Sierra, but just updating Safari, iTunes, etc. When I clicked the install button, it asked for my iTunes credentials, then asked for a code sent to another machine. This time, I didn’t have another machine nearby. The other option was to send a code to my phone – which I also did not have near me. So, that upgrade did not happen. It is frustrating to me that I increasingly need my phone to log into a website or perform other online functions. Even more frustrating, is it really necessary for me to jump through so many security hoops just to upgrade my computer?

Accounting Woes

Since the dawn of banking, people have needed to balance their checkbooks. Business or personal, the need is the same. Then, with the advent of personal computers, accounting software like Quicken, QuickBooks, Microsoft Money, and various others simplified the process. No need to do math, just enter your receipts and verify with your bank statement at the end of the month. Then, during the last decade we saw the emergence of online tools such as Mint and QuickBooks Online for accounting. No longer do you need to manually enter any accounting data – just provide your bank account information and allow the website to sync your data. No need to balance your checkbook or do anything at all. Just sit back and take an autopilot approach to much of the accounting work. Now, during this past year, I have seen a huge surge in problems with this kind of software. Banking sites are increasing security, updating technology, and – in general – breaking compatibility with these services. What was previously a 30 second process to update your account now takes minutes, if it completes at all. Some accounts demand that you enter an access code sent to your phone. Even more annoying, some accounts ask you to identify all the street signs or cars or stores in a picture. In short, the solution is now becoming more painful than the problem it is intended to alleviate. I hope this trend soon reverses, I love the simplicity that integrating my accounting software with my bank offers, but I am getting tired of wondering if it will work today

Now on WordPress!

Today, I have upgraded my blog to use WordPress. Woohoo! Up till this point, I had been using the built-in blog plugin for RapidWeaver. It works nice, but WordPress will help me take my blogging to the next level. Most importantly, I can now blog from anywhere instead of just my home machine. The bad news? Links I have tweeted or posted on my LinkedIn page are now broken. So, I’ll be working to fix that and to make the style between my main site and my blog look more… well… consistent.