I’ve been grappling with a bit of personal reality as of late. I do technical articles/posts on DevOps topics, I consult on (and perform) DevOps at work, and when I teach people how to program I accidentally teach them a bit of DevOps in the process. The problem is this: I don’t want to be called DevOps.
“But Andy, why don’t you want to be called DevOps?! It’s so great! And it’s just a name.”
I’m so glad you asked, and I’ll do my best to keep it simple. Let’s all agree that DevOps (as it relates to software development) is the concept of increasing communication and collaboration as well as cross-specialization for the purpose of building better software. Sounds great, which is why it’s what people have done for decades before the term DevOps was uttered.
Before people had phones more powerful than the things that sent us to the moon, before we could bicker over functional vs imperative paradigms, and before we had operating systems named after furry death machines, people had to create computers. The ones who did this weren’t computer scientists (and certainly weren’t Rockstars, Gurus, Ninjas, or anything else that absurd). They were mathematicians, engineers, and maybe sometimes chemists. They had other jobs and plans, and things that could’ve used automation.
Those people who did the most for our industry were often doing so because programming/sysadmin simply were unfortunate enough to get in the way. And though I certainly wouldn’t claim I’ve done anything useful or great for the industry, I can at least relate to programming and system administration getting in my way from time to time.
I taught myself how to program, and in the process I had no choice but to learn how to keep an eye on the quality of my software, how to get rid of menial tasks for deployment, and how to communicate what I wanted/needed with my collaborators and clients. I didn’t do those things because I wanted to expand my areas of expertise, I did them because I was annoyed and was sick of waiting for something or someone to do it for me.
When I say that I don’t want to be called DevOps, it’s really just me being frustrated. This term, which apparently is a very big deal these days, is yet another industry repackaging of something most great engineers do anyway.
So just remember… I’m not DevOps, I’m just an engineer who has a lot of things in his way on a daily basis.
Things will be a little different this time. With the two previous entries in this series, I was recapping work on a new idea/project and had to relay information about the project. This time, however, I’m simply extending Part 1 into the mobile arena and trying out some “new” technologies. That disclaimer done…here we go!
A Recap: SlimSocial
SlimSocial is the fledgling social network devoted to making “being social” more difficult. The key limiter was that a person can only post once per day, in theory cutting down on the useless chatter that happens constantly.
After pushing out SlimSocial, several of my good (aka misguided) friends decided to latch onto the idea and enjoyed the concept. It didn’t take very long for the first “can you make it work on my phone” request to come through, and after the fourth or fifth in a row I begrudgingly admitted that I could probably look into making a set of apps. I made sure to stress to each person that it was a lot of work and unlikely to be something I’d complete for months.
So of course, I started on it a couple days later when I’d finished working on Part 2.
Executing (aka Enter Cordova & AngularJS)
Last year at Microsoft’s //Build conference, they made a pretty big deal about their new cross-platform features in Visual Studio. I’d avoided it, as my past work with cross-platform mobile development via Marmalade proved to be tiresome and less than smooth, but I decided I had an opportunity to give the whole package a shot.
One of the other things I’ve been avoiding has been the concept of SPA (Single Page Application) frameworks (Angular, React, Riot, etc). Generally speaking, I find the whole idea to be a quick way to ask for trouble with performance, and they just seemed like trouble to learn.
So there it was. I felt I had the opportunity to learn two new things, and I took that opportunity. After finishing the game engine for Part 2, I continued streaming on Twitch while I fumbled my way through learning both AngularJS and Cordova at the same time within Visual Studio 2015. In the end, I’d say I managed to dump an obscene amount of my free time into this extension of SlimSocial, but on account of forgetting to track my time we’ll just put the estimate around 80 hours.
If you’re reading this and are expecting me to begin expounding the merits of both Cordova and Angular, you should probably stop reading now.
Now…I can be pretty opinionated. I’m aware it may be a bit of a character flaw, but it’s part of me so you’ll either learn to ignore it or you’ll go away. Learning two new technologies at the same time goes against some hard-learned lessons for me, but it’s not as though I intend for SlimSocial to ever be a serious time-sink (I understand that it has become one, but we’re talking intentions here).
Cordova seems like a pretty promising bit of technology. It’s not as though it’s a new piece of technology, I remember PhoneGap and others being around nearly 4-5 years ago, but it’s not the sort of thing I like to use on account of much of my mobile work having very specific performance requirements that can’t be achieved by wrapping an app within an app (which is basically how Cordova works).
That said, it’s not perfect. Some of the workflow can be aggravating, and figuring out how to configure things on the different machines, while not bad, is far from perfect. Even so, I imagine whenever I have projects in the future that don’t need me to squeeze every ounce of clock speed I can out of a phone I’ll be turning again to Cordova and its VS 2015 integrations.
And then there’s Angular… I can’t tell you how many times I’ve been told I need to learn Angular/React/Riot/Backbone/Knockout/Whatever. It’s borderline ridiculous how many frameworks there are that achieve more or less the same thing. Angular’s learning curve is pretty fascinating as well, starting off shallow when you look at the tutorials, and then taking a curve so steep that it feels similar to running into a wall head-first.
Angular calls itself “Superheroic” on their website, which is a pretty vague thing. Does it work? Sure. Does it do so in a way that’s easy to grep? Not at all. You have to learn intricacies of the entire framework in order to do even marginally complex actions for your app. You also need to grapple with incomplete and/or insufficient documentation when trying to learn said intricacies, basically relying on Bing or Google to show you the dark corners of StackOverflow where your answers lie.
I’ll try out Angular and one of the other frameworks for another project or two, just to be sure I’m giving it a fair shot, but thus far my decision to stay away from these libraries is feeling pretty justified.
Conclusion & Reveal
Once again with SlimSocial, I had hoped to make my prototype over the course of a weekend. This estimate was built off of my experience with doing prototype mobile development natively, and thanks to the learning curves of both Cordova and Angular I was about as far from correct as could possibly be (which is the reason I have a personal rule to not learn new technologies for business critical projects).
Adding onto this, there is a problem with distribution. In order for me to properly make this app available to individuals who aren’t interested in testing, I’ll be shelling out some serious dough to Apple and Microsoft (and subjecting myself to the chaos that is the Android build process). I’m not sure how willing I am to do that for SlimSocial. However, when the day comes that I do renew my Apple and Microsoft developer accounts, I’ll probably publish this immediately. Until then, enjoy some screenshots of the app working on my Windows 10 desktop.
The Idea: Outmoded
A friend visited me recently in Boston, and while we were being typical lazy gentlemen, the prospect of developing a game together at this year’s Global Game Jam (GGJ) surfaced. Though lately I’ve found it hard to be interested in anything to do with games or game development, but we agreed we’d like to make something without “graphics” that simply ran in the console. And so it was, that I created a project called “Outmoded.”
The first revision of Outmoded was done over two days while at the Barker Engineering Library in MIT. I chose C# so that I could finish the work in a few hours, and I’d estimate a total effort of about 5 hours was put into the project. The system worked within acceptable constraints and only had problems if you found yourself clearing the entire screen repeatedly for animation effects.
However, as the GGJ drew gloser, Alex asked if it wouldn’t be more performant to build the system in C++. Anyone who knows me well knows that I have an addictive relationship with C++, so ultimately it took very little for him to convince me this was the obviously correct path for the project. I created an experimental branch, scrapped the code, and got to work.
Over a couple work sessions I rewrote everything and had a simplistic proof of concept working on both Windows and certain flavors of Linux/BSD/OSX.
As it turns out, moving to C++ was potentially a final nail in the coffin for the GGJ collaboration. Though I got to relearn things I hadn’t used in well over a decade (potentially closer to 15 years), makefiles were never a strong suit and OS X appears to have some fascinating ideas on development, which is no surprise to anyone who has used XCode. Also, there was a lot of struggling with Clang as the compiler on Linux, eventually forcing me to revert to g++ in order to get the makefile working.
This was excellent practice for some upcoming cross-platform C++ work I’ll be doing before the summer, and I’ll be very thankful for the rust removal this work provided. There’s a very obvious advantage for using Windows as a development environment, I was much more productive/effective there than on Linux.
Conclusion & Reveal
The GGJ theme, “Ritual”, seemed like a great opportunity to build an interesting yet simple game, but the fatigue of debugging the engine’s production proved too much of a negative for some of the team. Thus we have opted to bury the project and explore other avenues. What does that mean for Outmoded? Not much, frankly. I’ll probably fix the remaining bugs if they aren’t too troublesome and maybe add a frame feature, but I’ve gone well past the amount of time I intended to pour into this trivial thing.
Years ago while working and living in North Carolina, my friends and I attempted to start a series of thought experiments together for tackling purely hypothetical questions. This was the one question we managed to complete, posted in the hopes that we can again try turning this into a monthly occurrence.
“Assuming time is non-linear, what is a better way to notate the age of an entity?”
LS (Liam S), AM (Andrew M), MH (Matt H)
Proposition: give up on measuring time. Time is usually a proxy for experience, or for progression through a known process (like a chemical reaction, or the steady draining of sand through a hourglass). Whenever we forget that, we create rules that end up making very little actual sense. Like the ones that make it illegal to drink alcohol on one day, but perfectly legal a mere 24 hours later (or if you know your exact time of birth, from one minute/second/etc to the next). In fact, time is a truly crappy proxy for deciding how responsibly someone will act in relation to alcohol. It’s a truly crappy proxy for deciding how responsibly a given person will be in relation to just about anything.
Give up on judging things by the proxy of time, and do direct measurements of what you want to know, on the particular case you want to know about. Somebody has been out traveling at very near the speed of light and they have returned? Well, who cares what their clock said or what your clock said. Are they showing signs of being mature enough to engage in whatever your proposed activity is? Did they experience the things they will need in order to react appropriately to a given activity? Note that those two answers might be different for the same person, and the same activity.
Time isn’t just a crappy proxy for human maturity. it’s a crappy proxy for a number of the things we like to think it’s a good proxy for, like the breakdown of unstable nuclei. All you can say about that, is that if nothing unexpected happens, then it will take X time for half the nuclei to decay. But in reality, there are a number of things that can happen to speed or slow the rate of decay from the one expected. So, sure, in a lab’s controlled conditions, you can make assumptions about breakdown given the time, and knowing how much lead shielding you need to keep from giving yourself cancer. But anywhere else, you better not assume anything and instead just measure with your Geiger-counter.
LS & AM
We interpreted the question as asking to devise a scientifically consistent and tangible measure for expressing the duration of a period. Put more simply: what’s another way to measure time without using the made-up construct that is time?
The goal of metrics are to provide understandable and convertible figures by which we can understand things that happen within the universe. Be it how long it has been since an animal has been born, the period which encompasses one object’s passage around another’s in space, or how quickly an object is traveling relative to another distant object. Linear time is, as far as we currently know, not a verifiable substance in the universe. It is an abstract concept we have created to provide common measure when discussing the passage of existence.
There are certainly relative measures you could use for each object. For a human being you could count the number of heart beats they have produced, the number of breaths they have taken, or the amount of steps they have traveled since their birth. Orbiting objects could be measured by both the distance they travel in their orbit and the number of times they have orbited. Finally, determining the speed of an object in space relative to another can be measured in combinations of distance traveled per rotation on the item’s axis.
The problem, though, is that each of these relative measures is fantastic at giving metrics specific to that object, but terrible at translating them into something that is usable for communicating those differences among disparate objects. Just as an example, basing your age off of the number of heart beats fails to communicate to others measuring similarly how different your heart rate is to theirs, how often your heart rate varies based on fitness levels, etc. There are analogous problems with the other measurements for orbiting objects and relative speed. Each measurement on its own is useful but is almost hopeless for making comparisons between even remotely equivalent objects.
Given the above and the circumstance of the question, finding a better way to notate ‘age’ for an object is about finding a common measure for how long the object has existed. In needing it to be common or universal, you are limited to things such as distance and energy. The
system you would create to provide convertible measurements for everything based on something like distance or energy would be extraordinarily complex and likely eventually found to also be just as relative as any other system.
All of that being said, it is important that Liam receive credit for coming the closest to an actual solution with his idea to measure the number of neutrinos that have passed through the object. It is known that the number of collisions experienced with neutrinos is extraordinarily small with known matter, thus making it fairly reliable assuming neutrinos are equally present in all parts of the universe. It’s not a perfect solution, but it’s pretty interesting!
Lately I've been spending a lot of time at home, which has produced an odd side effect. It seems the more time I am left alone, the more I get stuck on ideas without real merit. Generally speaking, these are passing thoughts at best, but sometimes one takes root and seems dedicated to obstructing real productive thought.
In past years, I've simply bided my time until the thought eventually passed. The more recent thoughts, however, don't seem to be following the pattern. Whether because of changes in my personal life, or the ongoing process of maturing, I find myself having to invent new methods for clearing my mind. And so we find ourselves here, dear reader, where I will attempt to quickly bring these concepts to life and subject you to the process.
The Idea: SlimSocial
At heart I am most comfortable playing the role of an introvert. As such, the world of social networking is irksome to say the least. Don't get me wrong, I have met many great friends thanks to the internet, but I also think they talk too much at times. With that in mind, I'd like to introduce you to "SlimSocial," my solution to social-overload on the internet.
Instead of allowing everyone to talk so much, I wanted to create a simple network that limited the number of posts someone could make per day. Initially, I'd envisioned limiting everyone to one post per day, and most of my prototype work has been done with that in mind. If I were to put more work into the system, it would be more appropriate to generate a system on top of the "likes" and "dislikes" a person accumulates.
Speaking of likes/dislikes, since I'm robbing people of the ability to flood the network with their idle musings, I certainly can't take away their ability to show support or disdain for their fellow network members. Still, I couldn't quite re-use the terminology of sites like Facebook, Reddit, etc. I spent a while racking my brain on what to call this feature, and eventually got a helping hand from Jordan. He took the "Slim" in the title a bit more anatomically, and suggested the system use weight loss or gain to represent likes and dislikes, respectively. Imagining the confusion this could cause, I quickly jumped on the idea and the chance to further solidify the network's uselessness.
There aren't really any interesting tech notes for this project, except to say that there aren't any interesting tech notes. What I mean by that is that I decided to forego utilizing any frameworks outside of jQuery and Boostrap on the UI. This was the first PHP project I've done in years without my framework (N2F) save for a game to keep tallies of annoying phrases on phone calls I did for a friend over the course of 2 hours. The whole experience was...enlightening. I can now say I know what parts of my framework are the crucial ones that really do save me lots of work. Beyond that, I might say I got to practice a little more with build/release automation in TeamCity, but that was less a goal for the project than it was a result of my server outage.
Conclusion & Reveal
I had hoped to make the prototype for this project over the course of a weekend. The mockup took about an hour after I found a template, but the remainder of the work was broken up due to said server outage, the holidays, and of course my day job. I'd estimate I spent 4 full days of work (32 hours) on the project to get it to where it sits today. The prototype is essentially complete, and though there is obviously more work to do, it is time to move on...or so I hope.
At my job we use Powershell a lot. I’ve always known that PS was a pretty powerful beast (you can have it compile C# for you on the fly to build more complex commands…that aint bad!), but as I’ve spent more time with it on an almost daily basis I have come to love it for a lot of different reasons.
As I fall harder for Powershell, I’ve decided to start hosting some of my scripts and modifications to scripts for others to use. Follow the link below and I’ve included some simple instructions. If you have any question (or suggestions), let me know!
[UPDATE: 01/30/2014] I have been informed by a friend that common terms for these two types of repositories are 'generic' and 'specific'. As a result, I have updated the post to use this terminology instead of what I'd chosen (monolithic and disparate).
Having finally found myself being introduced to the finer points of computer science at my new job, I am enjoying the foray into a touch of philosophical programming discussion. This will be (hopefully) the first in a haphazard series of posts outlining my own thoughts on those discussions. Full disclaimer, I am still pretty new to correct terminology and thus likely to fumble with their use…I’m not sorry, but I also don’t mind being corrected.
Repository (As I Learned)
When I first learned of the Repository pattern, I was shown an approach to encapsulating access to data entities that simply removed the business layer from having to touch queries. You provided an object that wrapped around your entity and thus made it so there was only one place to go when it came to add/edit/delete methods used by the rest of your code. A simplified example of this might look like this:
It’s simple, and it tends to significantly clean up your business logic if you’re the kind of person who just tosses their queries hither and tither.
One coworker seems to have coined the term ‘monolithic repository’ when trying to describe this approach, and I’ll be using the word ‘monolithic’ moving forward. Apologies to anyone who thinks they came up with it first. The common way to refer to this approach seems to be calling it a 'specific repository', so we will be referring to this hereafter as 'specific'.
IRepository and IUnitOfWork
At work we are beginning to implement what I have been told is a “pure” version of the repository pattern. As it was explained to me, there are really two patterns, the first being the Repository and the second being the UnitOfWork. To simplify what I was told, you would say that a Repository provides access to a set of data and UnitOfWork writes any changes to the set of data to their source.
In order to accomplish this we’re using a bit of dependency injection (DI) along with two interfaces:
We also have a Repository<T> class and IUnitOfWork<T> class which are used by the DI to satisfy the requirements a class may have. The implementations can be found pretty easily with a web search, so I hope you don’t mind me skipping them for now.
For the sake of this post, I will be referring to this approach as ‘disparate’. The common way of referring to this approach is to use the terminology 'generic repository', so we'll use that from here on out.
Bridging the Gap
The specific approach provides repository objects which are fairly customized for entity interactions. Initially the generic approach does not, but there is a fairly easy way to overcome that in C# using extension methods:
Since we are using DI in our system, we know that we will always be initially referencing the repository dependencies by their interface, IRepository<T>. With this in mind, we can easily create an extension method for all sub-classes of the interface giving them access to the FindUsersByEmail() method, just as we had implemented with the specific approach.
The specific approach can easily be rearranged to reflect the basic UnitOfWork separation from the Find/Add/Remove methods, so I won’t waste the space showing the simple movement of the Db.SaveChanges() call into its own method.
Fight! (And Conclusion)
Ok so there isn’t really a fight here, at least not from my perspective. Both approaches afford the ability to swap out sub-classes and instead use mock data storage (probably through a List<T> or similar) for building unit tests. Both approaches encourage users to keep their business logic devoid of direct queries to the data layer (assuming you use something similar to the extension methods above to provide custom entity-specific methods for the generic repositories). It almost feels as if the choice between the two comes down to a personal preference, since with either I can easily implement the behavior of its counterpart.
Still, the times that I have discussed this with my coworkers I got the sense that there was a natural desire to side one way or the other. Purists seem to prefer generic while pragmatists mostly side with specific.
One of the reasons I wanted to write this post is to see if anyone could show reasons one approach is truly better than the other. Do they perform differently to an extent worth citing? Are they easier to implement than the other? Do they save significant effort? I certainly can’t say. My only thought is that it would be much more difficult to adapt the generic approach to a data access system which doesn’t rely on in-memory storage of change sets (perhaps direct SQL).
Regardless of the result of any argument, it’s at least been fun grilling coworkers. Here’s hoping this is just the beginning of the study of the ‘finer points’ in programming.
I've been doing a lot of work recently with Marmalade on some mobile applications. In the process, I've slowly fallen out of love with the build process that Marmalade provides, mostly as a result of the signing process required to publish iOS builds. I won't weigh in on where the blame should rest for this ire of productivity, but I might as well share one of the tiny things I did to make things go ever-so-slightly faster.
We use TestFlight internally for build test distribution, so the process for distributing each build to the testers looks thus:
- Write code, watch code fail, fix code
- Test locally with emulator and USB connected devices
- Build on GCC ARM Release to launch the Marmalade Deployment Tool and package for both iOS and Android
- Launch Marmalade iPhone Re-Signer to Re-Sign the IPA for your selected provisioning profile
- Remember you have to move the base certificates into the deployment folder when the Re-Signer tells you it failed
- Let loose mumble of vulgarity OR Pull out small patch of hair to imprint that this is bad behavior
- Find the certificates and copy them to the deployment folder with the IPA
- Run Re-Signer again
- Upload builds to TestFlight
The process isn't hard, by any reckoning, but there were...undesired consequences for some of the team members.
Obviously, something had to change. I weighed my options quickly and simply created a BATCH file to take care of launching the iPhone Re-Signer. Instead of simply launching it, the BATCH attempts to copy the required certificates into the deployment folder before launch. I haven't had a chance to make it configurable for multiple projects, but I'll just update the code here whenever I do have that time. Hope it helps someone!
D: cd \Tattoo\Clients\PlateShare\Apps\PlateShare\build_plateshare_vc11\deployments\iPhone\iphone\release mkdir certificates cd certificates xcopy "D:\Marmalade\6.3\s3e\deploy\plugins\iphone\certificates\Apple Root CA.cer" /y xcopy "D:\Marmalade\6.3\s3e\deploy\plugins\iphone\certificates\AppleWWDRCA.cer" /y xcopy "D:\Marmalade\6.3\s3e\deploy\plugins\iphone\certificates\developer_identity.cer" /y xcopy "D:\Marmalade\6.3\s3e\deploy\plugins\iphone\certificates\developer_identity.key" /y xcopy "D:\Marmalade\6.3\s3e\deploy\plugins\iphone\certificates\distribution_identity.cer" /y xcopy "D:\Marmalade\6.3\s3e\deploy\plugins\iphone\certificates\distribution_identity.key" /y start D:\Marmalade\6.3\tools\IPhoneSigner\IPhoneSigner.exe