• Edutudu Part III: Vapor API

    In the last post I created a simple model of data and compiled the app, but I commented out a portion of the templated code to do so. This portion dealt with persistence of the data and routing the data through a controller. My original intent was to hook into a MySQL database, but I think for the purposes of this exercise, I am going to keep the SQLite database. The principle is the same, and I may return to enhance the persistence later. For now, though, I’m going to continue by fleshing out the web API.

  • Edutudu Part II: Vapor Data

    I love data. Data is the lifeblood of any application. Table views? Full of data. Email? Nothing but data. What is Instagram the app but a shell to hold the data of pictures and posts? I love a great UI. Native platforms have the best ability to create smooth, interactive, natural experiences and fluid animations that can be just plain gorgeous. Developing these UIs is deeply satisfying. But that UI needs to be filled with data, or it’s just a lifeless picture frame.

  • Edutudu Part I: Vapor

    In writing a full stack To Do app for my own education, an Edutudu, I am going to start with a Vapor web service. This of course raises two questions: why start with a web service, and why Vapor?

  • iOS 13 New Tech

    This massive WWDC introduced a number of new APIs and tools, such as SwiftUI, Combine, and Swift Package Manager support in Xcode. In addition, there are other community efforts like Vapor and Kitura that I have not have time nor cause to use.

  • Big Shop Process for the Small Shop

    While there’s a lot of discussion of programming tips and tricks, of the latest APIs and libraries, I wanted to discuss a little of the practice of software engineering, of the scaffolding around the procedure of writing code that helps to enable that code to go out into the world and help the people that use it. There are number of processes in place in bigger development shops which are also of benefit to the small, or one-person, firm. Some of these are basic, others may seem overkill for one person. You don’t have to do them all, or do them as I lay out here. However, done well, they help the generation and smooth the delivery of quality code.

  • A Seismic Shift

    Did you feel that last week? If you are a developer on an Apple platform, did you feel that shift during WWDC?

  • Solid Engineering - D is for Dependency Inversion

    Despite sounding similar, this SOLID principle is Dependency Inversion, which is not Dependency Injection. Dependency Injection is simply the design of a class such that everything it needs is passed into it, which helps with such goals as single responsibility, unit testing, and removing hidden dependencies. Dependency Inversion, however, is an inversion in the way that some might think about software development. It is two rules:

  • Solid Engineering - I is for Interface Segregation

    Keeping the hot side hot and the cold side cold may have been a marketing or ecological failure, but keeping dissimilar responsibilities apart is just good object-oriented programming, and is today’s SOLID principle: the Interface Separation principle.

  • Solid Engineering - L is for Liskov Substitution

    Halfway through SOLID we find the letter L. This stands for the Liskov Substitution Principle. Since it’s self-evident what this means, we can move on.

  • Designing an Apple Watch App

    Similar to others, I found that when the concepts of a watch app meet actual hardware, the ideas give way to reality.

  • Solid Engineering - O is for Open/Closed

    Our next stop on the SOLID tour is the Open/Closed principle. Bertrand Meyer coined this phrase, saying that classes should be “open for extension, but closed for modification”. What this means is that once defined, classes should not be edited in order to add features.

  • Solid Engineering - S is for Single Responsibility

    Suppose you were writing a server. This server needed to serve a graph of data objects. Furthermore, the data needed to be delivered in XML. So, you write a nice interface and add a simple method to each data object:

  • Solid Engineering - Introduction

    When discussing and thinking about the engineering of software, I often think in terms of solid engineering. What I mean by this is the dictionary definition of solid: something strong and stable, well made and dependable. Experience brings with it insight into patterns of construction, and an ability to recognize the wisdom that others share. Certain things in software development occur again and again, and these often have an available solution that will increase the dependability and stability of the whole codebase, proven through unit testing.

  • A Question of Competence

    Years ago, when I had a (lamentably lost) personal journal, I wrote about a number of personal topics. At the time, I was reading many technical blogs, sharpening my knowledge, but when I sat down to write, it was almost invariably non-technical. I thought occasionally about adding my voice to the programming world, but, really, what did I have to say? Anything I could think of to write about, I could easily find better examples of elsewhere online. Any challenge that I had solved recently was usually with advice found on other blogs, and didn’t seem worth talking about.