Category Archives: programming

Finally released: new KrakenFX app to trade on the Kraken exchange

apps, programming

Over one year ago, after noticing the lack of a mobile app to trade on the Kraken exchange, I set out to build one. A good opportunity to learn React Native I thought. After some months of hard work it had all I wanted. But when I was already using it myself for a while I lost interest. Well, maybe also because the whole crypto market crashed. Anyway, I (literally) took distance and started traveling again.

But a little over a month ago I broke my hip and could only lie down. I was separated from the world and stepped into my programming bubble once again. And so I finally manage to finish up the app, so I hereby want to present to you the first production release of the new KrakOn app for Android (iOS still pending review).

I specifically wanted the app to stay simple, beautiful and easy to use. Because some of these apps out there are so ugly and hard to grasp, it just made me cry ;p

So why don’t you head over to the Play Store and try it out? It makes trading on Kraken fun again. Their api rarely times out nowadays, which tells me that Kraken has made an effort to stay in the game as one of the major exchanges.

iOS 12 shortcuts review

apps, programming

The purchase of the Workflow app by Apple, and releasing it as Shortcuts app in their latest iOS 12 release, is a step forward in personal automation if you ask me. A huge step, but let’s zoom in to what is possible from a developers standpoint.

Shortcuts are a succession of actions, like ones interfacing with the native device capabilities exposed (camera, maps, text messaging etc), script actions such as setting/getting a variable and looping over a list of found/selected items, or even other inline shortcuts. When working with them you find that you can almost always find a way to realize the idea in your head with the building blocks provided. But that is exactly the limitation of the current implementation. They are linearly executed predefined building blocks that take an input and create an output. This leads to very cumbersome programming, with simple constructs like filtering/sorting becoming a huge headache.

In order to execute function-like behaviour you typically first park the main threads value in a variable, then extract what you need into new variables, do some processing (recursion or looping bringing even more headaches), and then ‘get variable’ to come back to the main thread. I find myself wishing for a real scripting environment all the time. Of course Apple tries to keep the attack vectors to a minimum with this approach, but maybe in the future a proofing layer over a scripted approach can achieve the same result. Making us developers happy shortcut coders.

But, being a power user seeing automation possibilities first of all, I felt the need to create some shortcuts. I spent quite some moments in my car lately, and am disappointed about Siri’s shortcomings when it comes to dictation in other languages and delegating results to other apps. So I created the following shortcuts:

  1. Dictate to Siri in my native language (Dutch), while operating her in English, and copying what I said to the clipboard (to be used in subsequent actions).
  2. Run other shortcuts that take clipboard contents as input, like automatically translating to english.
  3. Match a certain contact from voice/clipboard input  (like from step 1)
  4. Extract maps location from voice/clipboard (which can contain an address of type Text, or a found Contact with one or more addresses)
  5. Navigate  to (selected/clipped text, apple maps location or contact) with the app of my choice: Waze, sometimes Google Maps.
  6. Drive to a contact, or home, with Waze.

As you can see I have named the shortcuts with “>” in front (expressing it expects a previous input), or with “>” behind (expressing it is a building block for other shortcuts). I hope these shortcuts and it’s implementation details can serve you as well. I still have to find out how to publish my shortcuts in an open source manner like on GitHub. Maybe I will just create a repo with a doc of iCloud hosted shortcut URLs.

UPDATE: I have done just that and published my GitHub hosted shortcuts.

Have fun breaking your head over this new functionality!

Coming back to Kubernetes

programming

After traveling for a long time I started playing with tech again. I started building a crypto currency trading app for the Kraken Exchange API. The resulting app can be downloaded here: expo.io/@morriz/krakenfx-react-native.

But then I started playing with Kubernetes again, and started working on mostack: a stack with Kubernetes best practices. This was a hard and long road past obscure pitfalls and learnings. Some I just have to give back in the hope you may avoid them.

Drone CI/CD.

To automate software building we need a CI/CD build system. I chose to go with Drone, as I like the simplicity of working with docker containers, and it’s open source and not SaaS. But Drone uses Docker in Docker (dind) and that gave me the following problem:

Drone starts the host docker container running the dind with a custom network. Probably for good reasons, but this makes it impossible to resolve any cluster ips from known kubernetes service names.
I needed to docker push to a locally running docker-registry service, as well as make kubectltell the api server to update deployments. Since there is no way around this, I had to use the host docker socket and manually instrument the wiring of the plugins. Including the custom dns settings. Please see the .drone.yml in the morriz/nodejs-demo-api how I did that. For more information around my dns related issues see my posts in the drone discourse .

Helm

The biggest challenge in k8s userland is the deployment of the manifests. Ideally one would like to have a uniform approach to apply the entire new desired cluster state in one go. Preferably automated after a git push to the cluster repo. For now I chose to experiment with Helm, which allows me to make one root ‘Chart’ (the name they use for a ‘package’) for the entire cluster, with app subcharts that describe the components running on the cluster. But somehow the Helm people have decided to use a ‘Tiller’, which is an agent pod listening to the helm client. Supposedly it helps in managing the cluster, but the logician in me says it goes against the unidirectional flow of stateless architectures. I wanted to avoid running the agent, and luckily the ‘template’ helm plugin lets met do that. You can install it with helm plugin install https://github.com/technosophos/helm-template. Now we can just apply the entire application state (from the root folder) like this: helm template -r mostack . | kubectl apply -f -

Another downside to using helm is the fact that I can’t deploy subcharts in their own namespaces. But that option might come in the future.

Happy helming!

Milieuzone Utrecht app

apps, programming

De gemeente Utrecht is de eerste met een verbod op 15 jaar oude diesel auto’s in het centrum. Omdat ik het nogal problematisch vind om mijn 15 jaar oude BMW 530D -die ik met zoveel liefde heb behandeld- weg te doen, heb ik een app gemaakt die me waarschuwt wanneer ik de milieuzone nader.

Ik heb de app aangeboden aan de app store, en wacht op bevestiging. Ik heb hier alvast een pagina aangemaakt met details over de Mileuzone Utrecht app.

Ook heb ik hier een web versie online gezet: de web versie van de Milieuzone Utrecht app

Mocht je er wat aan hebben, dan zou ik het leuk vinden als je een reactie plaatst 🙂

Google’s golang for president

programming, ,

Being a hungry geek I can’t help myself from innovating myself, and so I read blogs here and there on the current state of software and architecture. But I didn’t really have any alarm bells going off the last couple of months when I came across Google’s Go language. I think it was just a classic example of my assumptions getting in the way (knowing Docker was built using Go, I figured it was some new low level generic language). But now that I finally started studying it, it appeals to me more and more.

You see, after having advocated Node.js for some years now, and seeing the architectural shift towards frontend middleware becoming a reality, I never really looked for anything better or more suited for that. And that is exactly where Go fits in. It’s such an elegant solution to the need of scalable applications that handle concurrency and parallelism gracefully. It’s still a functional language, but at the same time it’s blocking! It’s kinda weird that I am excited about that, since I have been addicted to events for the last years, and have a hard time shedding that skin. But I have seen the complexity of large scale applications that are built upon callbacks and promises, and it secretly made me wish for something simpler. Something that did not make us do custom code-(re)structuring all the time. But the flexibility just kept me in love and favor it above anything else.

And now I found Go, and Rust, but that is another story that might not have a happy ending.

Docker for finer grained DevOps

programming, , ,

While working with AWS’ rudimentary image bootstrapping, allowing me to either boot and configure from a supported image, or directly boot from our own custom image, I came to realize the price and frustration for this archaic mechanism of bringing up a new operational node to scale out or update/rollback nodes. There had to be a better way.

So I started looking around for other ways of deploying and managing infrastructure. And there was Docker! It was a couple of months old, but I was sure it would take the world by storm and started experimenting with it. It would allow me to build one image with all the necessary infrastructure to run an app, and deploy it everywhere! And if I needed to upgrade part(s) of the infrastructure, I could do so very easily, and just have my nodes update by pulling in diffs! Super cool!

Now I knew I was slowly being sucked into DevOps land, but just had to go with my guts and explore this beautiful new territory, even tho it wasn’t my core expertise I was building on. This attitude allowed me to dive right in and get to know the ins and outs and the do’s and dont’s of building docker architectures. I don’t want to give detailed instructions how to do things on this blog, because there is enough of that to be found, but let me just do what I do best, and that is to inspire others to try the stuff I am excited about.
And if it’s one thing I am very excited about, it is Docker and this whole new movement in DevOps land, with such things as CoreOS utilizing automated centralized configuration managment such as EtcD. There’s a whole slew of PaaS offerings coming our way, and our developers lives will be made a whole lot easier thanks to the initial work of the dotCloud people 🙂

Event store with Node.js and AWS

programming,

It’s been a while since I posted anything here, but a lot has happened on the front. I will give a quick update about the things that have interested me since then

In 2013 I created my first auto scalable event store architecture for a huge client in Node.js, involving custom web servers receiving events from different endpoints in different formats, meta-tagging them and then injecting them into amazon queues, with processors on the other end enriching and transforming the events for storage in AWS DynamoDB. Post processors would be run periodically to store aggregates in S3. It was required to auto-scale to handle 200.000 events per second. (Yes, you read that right). I created a stateless architecture with the code for all the roles (server, processor, post-processor etc), built into one repo, which would be tarred and deployed onto S3 by our Bamboo server, to allow new nodes to be bootstrapped with that. The node itself was already booted by puppet with a role to perform, and thus knew it’s role to play. For hot upates and rollbacks we’d tell a Saltstack master to update a certain range of nodes, which would then pull the wanted source from the S3 registry again and update themselves without downtime. Pretty nifty, but rather proprietary.

The company I worked for used Puppet for configuration management, but also for app deployment, which I thought was the wrong approach. Puppet is imo not designed for realtime deployment, but rather for booting and maintaining vm’s from config. That is how I came across Saltstack’s powerful realtime command capabilities, and decided to script our deployment process to be controlled by Saltstack. I actually haven’t updated on that front in a long time, but I saw it fit the bill for our needs and I was so bold to build it into our POC.

Too bad we hadn’t learned about Google’s Go language back then, otherwise I would have scratched myself behind the ears and probably opted for that, instead of Node.js for our highly concurrent applications.

OSX – use the force

apps, programming, , ,

Ever since I was young I knew that I would be always automating a lot of my computer work, in order to achieve things better and faster. My motto became: fix it when it breaks, or needs fixing, and do it asap. That way you benefit immediately, and will save you time in the future.

After having tried Windows and Linux, I arrived at Mac OSX, which has more powertools than the other OS’s, and has the most user friendly Graphical User Interface. And all that on top of a UNIX base, allowing me to hack away in the terminal.

I have just updated my OSX apps section, where I list most of the apps that are essential to my everyday computing. I thought it wise to share ’em with you all.

To give your even more power user skills, I have also published Google documents of my last OSX power course training here:

Use the force Luke!

 

It’s all coming together now

personal, programming, ,

I was asked to speak for a small group of people on behalf of my Javascript expertise at a meeting of frontend web developers. Of course I said yes, and started thinking about it. I wanted to use my newly learned lessons from The Art of Hosting. I also told my host I wanted to take a personal approach, and would like to include my own stories. I said I wouldn’t be needing a beamer or flipover. He was very interested and let me go my way.

When we went to the presentation room, I saw a round table. Just big enough to host us all. We were with 9 people, so that created an intimate space.
I started with a check-in and asked each person to tell us who they are, what inspires them, and what they’d expect from the evening.
When the first person started all became engaged, and we listened with interest when each took their turn. Some talked about their professional self, others took a more personal route. Wonderful!
I felt my body relaxed, my mind clear, and was able to truly listen to the others, and get familiar with their faces. Questions were asked from genuine interest.

Finally I told my own story. I was able to be fully at ease and look everybody in the eye. That was a first for me, and I attribute that to the initial check-in round. And the small group as well.
I talked about my personality, my lack in degrees, my initial insecurities because of that, and how I overcame that by reading whatever I could about my area of expertise. About how I got to know myself better, enabling me to become more solid and gain integrity. That I sometimes need to manage my overenthusiasm.
The group responded multiple times by asking questions and recognitions.

In essence I was telling authentic stories, exposing my weaknesses, and how I gained strength by accepting and getting to know them. Their faces told me they were intrigued, sometimes amazed, but all of them were engaged. Some faces started showing minor agitation, which I think was some impatience for my build up, or the mismatch with their expectations.

So to move them towards the topic of the evening (Javascript) I then went on to speak about the moment I fell for Javascript, and who was on my path to inspire me.
I talked about my open source project called backbone-everywhere, and that it was meant to be a demo for a startup. This project involves bleeding edge open source javascript, which is common ground to most of us. So we ended with a discussion about our area of interest, which we all hoped to talk about.

Afterwards I asked them for feedback, what they thought about the format, about my way of hosting.
They all preferred our participatory setup over a regular presentation, and felt energized.
Because I hardly got any critical feedback I kept asking for it.
One person then told me he got a little bit frustrated for not knowing how and where it would go. I thanked him, and explained I am learning to detect such signals in the heat of the moment, so I can ask what is needed.
Some people told me that more structure in the informative section would be nice. I agreed there. The lack of a visual presentation gave them a new experience and engagement, but I realize that I should have some visual structure for stories that involve lots of technical aspects.

When most of the people were gone, I remained with the two intitators of the evening. They were very enthusastic about my approach and we talked setting up a new Javascript course together.
What an energizing and fruitful night! It’s wonderful to see everything come together, and life aspects seeping into work, and vice versa.

 

Android hemroids

apps, programming, , , , , , ,

I am a genuine late adopter of modern technology. I do see a lot of it coming from miles away tho, and try to get in touch with it before it arrives. Read up on it, let it sink into my stubborn brain cells.
And so I fell in love with Android long time before it was found on any commercial device. As a programmer I immediately fell for it’s architecture, it’s intents, it’s openness.
While waiting for the baby to mature, I read up on the first user experiences and decided to wait a year more, before trying it out myself. Being very fond of my iPhone User eXperience, and a Linux user, I was very reluctant to try another open source OS.

So I finally decided in 2010 to buy the Goog’s Nexus One, and treat myself to a whole different mobile experience. No cruft, straight up android from the core.
Nice new features, integrated messaging and notifications, free navigation, supported rooting, a dream come true from a programmer’s perspective!

But then the wet cement started coming up through the cracks, reminding me of the slow, shaky and ever evolving Linux OS’s. Why would it be different with Android? Marketing? A larger user base? Of course not. The foundation is the same. Openness breeds variety, and the lack of control allows buggy software. It just kills the user experience when there is no senior top of the pyramid overlooking a coherent interface to it’s OS, but also it’s ever growing list of apps.
Android’s choice to let performance measures come from the community itself, rather than exert dominant control over such an important aspect, resulted in an unresponsive and sluggish device. Trying and uninstalling many task killer and performance apps trained me to keep it into shape somewhat, but how cumbersome!
But the most irritating to me was the fact that the Android market became the waste bucket of successful iPhone apps, with even the largest web services out there offering alpha software. Not only were most of them very buggy, but it seemed that the android user base was treated like the linux user base, expected to not care about user experience, but openness and features only.

And that is what made me sell the device after 2 months of trying very hard to make the device perform acceptably, and go back to my good ol’ iPhone 3Gs.
So I decided to give Android more time to mature, and hoped the inevitable growth of it’s user base would demand top notch user experience. Boy was I wrong.

2 years after my first encounter I now own a quad core Asus eee prime monster tablet running the latest ice cream sandwich, holding more power than necessary for a smooth user experience. Or so I thought.
ICS 4.0.3 is still not controlling performance and has apps running wild, interfering with my user experience.
The apps I use most, such as Facebook, Spotify and Twitter, are all cream of the crap. Offering the same crappy UI and limited functionality like years before. But I can’t really blame app developers for not wanting to support an OS that does not deliver the same functionality on the multitude of devices churned out every day. I do have to see that as a given from now on I guess.

What was I thinking? I should have realized that the same lack of control over performance and apps, and also the increasing complexity of hardware support are truly hindering front of the line, top notch mobile device experiences.
Apple has been criticized by that same android community for exerting this kind of control, and app manufacturers have been honed for only supporting Apple’s stable unified hardware approach. But being an open source advocate, I am also a power user in need of a user experience allowing my quick and intuitive workflow. My day to day operations are not to be hindered by sluggy OS’s and unusable apps.
There is no choice for me but to go back to Apple’s stable, and ride their willing and able iron horse, taking me into the camps of the fronteers, letting me indulge in their nourishing stream of app cream.