http://rudiyardley.com/Ghost 0.7Sat, 04 Mar 2017 02:56:56 GMT60When creating great applications it is important to provide systems that allow features to be implemented and maintained as discrete units of code.

It is also important to avoid magic runtime binding where functionality is implied by folder structure or some other magic variables or constants.

ES6 modules have come

]]>http://rudiyardley.com/application-architecture-dynamic-loading-es6-modules-indexr/4abc1408-1063-44ba-870b-842281fc17e4Wed, 03 Aug 2016 09:38:18 GMTWhen creating great applications it is important to provide systems that allow features to be implemented and maintained as discrete units of code.

It is also important to avoid magic runtime binding where functionality is implied by folder structure or some other magic variables or constants.

ES6 modules have come along and they are a great way to organise JavaScript code. They are declarative and statically analysable. Very importantly what you see is what you get.

However they lack the ability to autoload modules on the fly based on a dynamic folder structure such as the kind you would see in a modular framework that needs to bind dynamic packages of code together.

What Indexr does is it takes a folder, searches for any 'module' folders based on globs you provide and generates index files that export all the 'submodules' within the 'module' folders in whatever way you choose.

]]>The brilliance of Redux lies in it's simplicity. Redux is so simple in fact that when thought of as a stream of states, it can be expressed in a single line of RxJS code.

I was working on a side project that manipulated streams of data and it occurred to

]]>http://rudiyardley.com/redux-single-line-of-code-rxjs/30e36e16-dc95-4942-a4b7-7a898dccddffThu, 16 Jun 2016 17:02:27 GMTThe brilliance of Redux lies in it's simplicity. Redux is so simple in fact that when thought of as a stream of states, it can be expressed in a single line of RxJS code.

I was working on a side project that manipulated streams of data and it occurred to me that streams might be a simple and flexible way to handle application state. In the process I discovered that with only one line of code I could get the same sort of core functionality provided by Redux using RxJS. This then provides access to a higher and more powerful abstraction and code vocabulary that can be used elsewhere to homogenise other varied asynchronous strategies such as Promises and callbacks.

So I thought I would write a little bit about the potential of RxJS as a replacement of Redux and provide an example of how to use RxJS to provide Redux style functionality.

Redux

Redux is a very successful interpretation of the Flux architecture to manage state in client-side applications.
The main concept around redux is that your app should only have a single data store and that data is a reduction of the previous state and the change brought about by a given action. React components are then connected to the data in the store with a set of utility functions and higher order components and as the store's data is changed through actions being fired so the view reacts.

RxJS

From their website: "Rx or Reactive Extensions is a library for composing asynchronous and event-based programs by using observable sequences."

What they mean here is that RxJS is a framework for working with streams of data over time as if they were arrays. So with RxJS instead of thinking of our application as a structure of objects communicating with one another we think of the application as a signal network through which data is sent through. Eventually at the output of the network a view callback will subscribe to a stream which will pass it a state that is rendered functionally. In most cases React would be the best choice for a renderer.

Redux is baked in to RxJS

The totally cool thing about RxJS is that the core functionality of Redux can be written using merely a single line of code. Following is how you implement the guts of Redux with RxJS Observables.

action$.scan(reducer).subscribe(renderer)

Yup that is the whole reduction and state management provided to you weighing in to a grand total of around one line of code and best of all there is no magic (assuming you are comfortable with the way streams work).

Breaking it down

So, for those uninitiated with Rx you are probably asking yourself 'What is going on here?'

The stream

Basically action$ is an Observable stream. The $ in the name is merely convention for showing that the variable is a stream. As an aside, personally I am not thrilled about using things like $ for naming conventions but it is prevalent within the RxJS community which is why I have included it here.

The reducer

The reducer is one of Dan Abramov's reducers; a function that takes a state and an action and immutably returns a newState. In a real app this would be composed of a bunch of other reducer functions combined in whatever way you see fit.

The renderer

The renderer is a function that takes a state and renders that state to a React component tree.

Reducing actions to state

Finally and most importantly, the poorly named .scan() method on the observable is the thing that gives us all the power here. This applies an "accumulation function" over our state$ stream and returns each result as more data comes down the stream.

So if you pass an action data object (however you want to define it) to the head of the action$ stream what happens next is that then out pops your resolved state at the other end thanks to your reducer function. The renderer can then render the output state on the view.

Example app

So maybe I was being a little misleading by saying it only takes a single line of code, however the core functionality is packed away so neatly by RxJS I think it is a rather tight implementation of the same idea as Redux.

Async actions

Let's say we want to do something asynchronous like fetch some information from a rest api all we need to do is send an ajax stream in place of our action payload and then use one of the lodash style stream operators, flatMap to squash the results of the asynchronous operation back onto the action$ stream.

The advantage of swapping the action payload for a stream is so we can send data updates at the start and the end of the async operation

ReactiveX enables better polyglot communication

In the end, the concepts within Redux are simply Functional Reactive Programming and with Rx being the cross language poster boy for FRP it makes sense that one can use Rx to create Redux.

What is interesting here, is that because Rx is available in 15 different programming languages using it to develop Flux style architectures as a technique will translate cross-language so it is theoretically plausible to use a Flux/Redux style pattern for state storage in languages like Ruby, C# or Java.

This is especially useful in my opinion if you are working in a multi service polyglot environment where occasionally your teams need to work on each others projects. You could be working on separate services but would have a shared functional approach to application state.

Don't ditch Redux

Using Redux is useful in terms of having a language around functional state reduction as a pattern. The tools it provides for debugging state are a great add-on.

This technique however, shows at it's core how simple Redux is and how your app framework actually need not be complex to be useful.

You may want to simply provide your own simple state management. The main benefit here is cutting down of magic you need to grok outside of your codebase and limiting your dependency graph.

If you are sure you will never use RxJS in your app and you want a FRP state store then using Redux makes sense, however in the case where the argument for observable streams has already been made or if your polyglot team has cross cutting concerns I think this is a contender for handling app state.

]]>I wanted to write a bit about the technology I have gravitated towards over the past couple of years and to talk a little bit about their strengths and weaknesses as well as how I have used the technology in the last few projects I have been involved in. Every]]>http://rudiyardley.com/tech/3a053837-43c7-4379-ad6d-f8f81ca2d43fFri, 08 Apr 2016 11:45:00 GMTI wanted to write a bit about the technology I have gravitated towards over the past couple of years and to talk a little bit about their strengths and weaknesses as well as how I have used the technology in the last few projects I have been involved in. Every project has slightly different goals and when I am commissioned to build a project I will almost always choose technology based on what fits the problem space and requirements whilst leveraging my skillset and experience. If I can't find a match that works for the customer I don't take the project.

Node JS

Serverside Runtime

Use of Javascript across the stack has many, many benefits to website developers and web application teams.

Developers need only learn a single language

Isomorphic/Universal app methodologies require tight coordination between client and serverside development. Ideally you want people to be able to bridge those gaps.

Reuse of packages clientside and serverside

Extremely active and changing technology ecosystem and a great community

Some folks hate JavaScript's quirks but personally I find it an efficient language to code in despite the gotcha's it is famous for. Fullstack JavaScript is here to stay, ES2016+ makes for a great programming experience and it is fantastic that we can use such a versatile language in modern web development.

ECMAScript 2016+

Courtesy of BabelJS

With the advent of ES2015+ JavaScript became one of the most feature rich modern programming languages around. The JavaScript community was yearning for a way to adopt modern programming ideas and paradigms so people were experimenting with CoffeeScript and DART compilation but finally we in the JavaScript community have a standard path to the future of JavaScript and this is a huge deal.

With new language features programmers can write expressive concise code that explains to the reader what the code is doing. Also by following standards we can be sure our code will not age as readily as older more verbose code or boutique side-steps like coffee script. This is important factor in finding developers that are willing to maintain our software for us.

One drawback is that different vendors release standards features at different rates and this coupled with users all running different browser and OS versions and the need for transpilation, or compilation to a language of similar abstraction, is understandable.

Babel has grown to be the industry standard for managing this process which is why I use it.

React

Functional view rendering

React is big news. Most large companies are leveraging the paradigm shift towards Functional Reactive Programming that React provides these days. React is great especially when state is shifted off to some kind of immutable state management framework such as Redux or even RxJS. With React it is faster for programmers to reason about how their interfaces work than without it, which saves money for business.

I prefer custom commercial projects that involve React as I think this way of thinking about interfaces makes sense in the vast majority of cases. There are certain performance sensitive cases where a different approach is best but for the most part React is an important tool for use in todays modern Web Applications.

Keystone.js

CMS for Node.js

I have built several projects in Keystone and so far Keystone has performed fantastically.

Keystone is an app framework built on Express and Mongoose and thus has with it the considerations you would have for using a NoSQL backend system. Most of my clients need a site up to power an MVP type app with a simple admin interface and Keystone fits the bill most of the time. Keystone is currently being rewritten using React to render it's page controls so once there is an API to render custom controls Keystone will become an incredibly versatile system and I am excited about it.

Ghost.js

Blogging for the 21st century

Ghost was built by John O'Nolan, the former deputy lead for Wordpress' UI team, after he became more and more frustrated that Wordpress' bloated backend is no longer a great fit for a pure blogging engine.

Ghost provides an amazing writing experience whilst posts are written in markdown which allows for users to focus on content whilst resolving rendering and copy/paste issues. It is customisable and configurable enough to handle all the needs of a basic content marketing blog. And it is Node so set up, hosting and maintenance is a no brainer. If a client needs a blog in a hurry I usually recommend ghost.

Shopify

Buy now buttons

Shopify for e-commerce has turned into an industry behemoth changing the industry with its offering. There are still usecases where the expensive hosting offered by shopify is not worth it so I have found success leveraging shopify's powerful functionality whilst cheaply hosting a small website by using the Buy Button API for shopify. Here is an example: http://pesado.com.au

Shopify Buy Buttons have a limited usecase but if you can fit it to your needs it ends up being a very cost effective build when compared to building out of a larger e-commerce offering.

Here I have written a bit about some of my preferred tools and technology I am using during 2016. There are a couple I will write about more in the future including the following:

]]>How to log into vagrant using nothing but the command line ssh client.

I wanted to log into a vagrant box over ssh the other day a while ago but was struggling so I left it. Now I just stumbled on how to do it so I thought I would

]]>http://rudiyardley.com/logging-in-to-vagrant-over-ssh/e22cda48-a9ee-4241-a20c-22ba13d50607Sat, 13 Feb 2016 04:23:18 GMTHow to log into vagrant using nothing but the command line ssh client.

I wanted to log into a vagrant box over ssh the other day a while ago but was struggling so I left it. Now I just stumbled on how to do it so I thought I would document.

Locate the private SSH key

Vagrant basically creates their own user for logging into vagrant boxes but aside from that vagrant actually creates a unique private key per machine for the user to log in with. When using VirtualBox as a VM provider the private key is located here:

So my version of Sublime Text got borked so I decided to set it up again and share all the packages and snippets I use during development in the hope that others find it useful.

This will likely change overtime and mainly here to serve as my reference but I hope that this might help someone get their dev environment setup a little quicker in the future.

My Setup

My environment takes a little while to setup but I have found it to be quite an efficient way to work as well as be an aesthetically pleasing work environment. It is important to have an aesthetically pleasing environment to work in especially as I have inherited designer's OCD from my years studying Multimedia Design.

My editor of choice is Sublime Text 3

My editor of choice is still Sublime Text 3. I Played with Atom for a while and got excited by it but found it slow and buggy. This was a while ago however things may have improved and I need to find out a bit more. I also have looked into vim. I love the idea of working solely in the terminal. I tried to have a play but struggle to keep up with the learning curve when I have serious work to do. I might give one of those a better shot at a later date.

NOTE: Be sure to head to the website to grab the latest script to use.

Install Predawn

With Package Control installed we can start installing packages so firstly we start by fixing up the file browser which is looking a little crappy. Installing the fantastic Predawn development theme will fix that:

Install Babel eslint

These are extensions to the ESLint binary itself so ESLint can deal with Babel based on the babel compiler. This kind of futureproofs the linting so that as new features get enabled they can get linted against.

So simple if you only set up the cascade as you run it instead of building a huge complex web of promises.

]]>I was reading the documentation for Facebook's Jest the other day and I noticed they suggest keeping your tests in an ugly test folder mainly so you don't need to have ridiculous require statements such as require('../../../../path/to/my/thing'). Well I am here to tell you there]]>http://rudiyardley.com/use-symlinks-to-avoid-require-hell/43ca4ee0-d300-46c5-a478-f07bbbbbe8bcFri, 27 Mar 2015 09:49:05 GMTI was reading the documentation for Facebook's Jest the other day and I noticed they suggest keeping your tests in an ugly test folder mainly so you don't need to have ridiculous require statements such as require('../../../../path/to/my/thing'). Well I am here to tell you there is an easier way.

All you need to do is to use a symlink to your folder in your npm ./node_modules and you can access your code pathed from anywhere. The only consideration is that you will have to ensure that your source folders don't use conflicting namespaces with the node modules you use.

There is even a cute little npm module to help you do it:

npm install link-package --save-dev

]]>From working with Rails over the last couple of years, I have become increasingly aware that the problem that server-side frameworks such as Rails are trying to solve are not the framework challenges that application frameworks will need to solve in the future. With the rise of component specialisation and]]>http://rudiyardley.com/first-impressions-of-meteor/33ae20ce-055b-4439-9187-fdef9143c229Thu, 05 Feb 2015 10:24:00 GMTFrom working with Rails over the last couple of years, I have become increasingly aware that the problem that server-side frameworks such as Rails are trying to solve are not the framework challenges that application frameworks will need to solve in the future. With the rise of component specialisation and service oriented architecture as well as the Node/io.js technologies bringing the dream of isometric application design to a new reality, it occurred to me someone really needs to write a framework that both shared data models whilst maintaining a strong service architecture. Needless to say I was impressed to discover that with Meteor it had already been done.

So I have decided to give Meteor a whirl and share my experiences live as I get to know the basics of working with Meteor by documenting them in a few blog posts.

So whilst I do certainly plan to write mainly awesome button click tracking apps for the rest of my foreseeable career, before I retire to the fridge to crack a cold one and admire all my fine handy work it might be intellectually stimulating and enlightening to have a little poke around at what has just been done by this this runtime in my name.

The app structure.

Let's load up the folder into sublime and poke around:

As you can see Meteor has created the 'app' files:

myapp.js

myapp.html

myapp.css

These files look like stubs for js, html and css respectively and assumably where the differentiating components of your app that make it your app are created. Meteor also seems to have created a '.meteor' folder which looks like it has configuration files and MongoDB files as well as a build folder that meteor probably runs a node server and serves out of.

One file defining both client and server.

The most striking thing about looking at this generated code is the way in which the JavaScript file generated appears to have been defined to run on BOTH the client as well as the server. Initially it's seems to me to be a little awkward to attempt to separate the two using a simple flag to tell us not to run the server code on the client and vice versa but thinking about it I can see some power with including the same libraries into both as you write modules that span both client and server and represent slices of functional interaction. I am writing this knowing very little about Meteor so for me right now whether or not Meteor actually works that way remains to be seen so lets dive into the docs and checkout whats going on.

So if we have a look at the above link it seems like Metor uses a kind of Handlebars style templating engine called spacebars to do templating and I have just decided I want to build an app that lists all the most popular javascript github repositories instead of a todo app so I am going to try hacking my template to list the repo name address and stars:

]]>I have been working on a spree application that I have "dockerised" and occasionally I would return to boot2docker and find an error starting up.

What this had meant was having to destroy the VM and then rebuilding all my containers. This was annoying an not very feasible as the

]]>http://rudiyardley.com/boo2docker-vm-machine-does-not-exist/ad1a86d5-e469-412a-90bd-5aa7cbfbef6aMon, 26 Jan 2015 01:51:06 GMTI have been working on a spree application that I have "dockerised" and occasionally I would return to boot2docker and find an error starting up.

What this had meant was having to destroy the VM and then rebuilding all my containers. This was annoying an not very feasible as the process for rebuilding containers required the download of a large dataset which was taking up to 20 minutes.

I stumbled on to this solution from stackoverflow that solved my problem and I thought I would share as for some reason it isn't marked as the correct answer.

This means I dont loose my containers and need to wait 20 minutes for everything to rebuild.

]]>For most of the last year I have been working with a large legacy Rails / AngularJS software application where we have HAML views that are enhanced with AngularJS directives.

Now Angular can certainly be effectively used that way but occasionally, it becomes clear, Angular is ultimately designed to work more

]]>http://rudiyardley.com/discovering-unrelated-child-elements-in-angularjs-directives/0383102b-6ab1-43ff-a1ae-94bbdd794d66Sat, 17 Jan 2015 01:32:27 GMTFor most of the last year I have been working with a large legacy Rails / AngularJS software application where we have HAML views that are enhanced with AngularJS directives.

Now Angular can certainly be effectively used that way but occasionally, it becomes clear, Angular is ultimately designed to work more as a monolithic application framework, as opposed to, a 'page enhancer' and there are certain problems that do crop up from time to time to remind you of this, as you bend it's usecase. One such issue prominent specifically with the Angular+Rails system is what I like to call 'php-fication' or the tendency to want to program your entire application in it's templating language.

How much logic can we stuff into HAML?

One frustrating problem is the tendency for both Angular and Rails to use views as dumping grounds for huge amounts of view logic that doesn't have a home anywhere else. In Rails it is as a result of a lack of decent view first design patterns within it's architecture. On the client-side, in our case, it is as a result of not handling templating within Angular so the declarative logic stays stuck on a single HAML view.

The end result are views with a fair amount of Ruby, Angular and DOM Javascript spaghetti all together, in the case of the app I have been working with, alongside a healthy dollop of SMACSS driven CSS adding it's own layer of confusion.

Decoupling Rails from Angular from CSS

This doesn't look too evil and wouldn't be if it was an excerpt from a template within an Angular component, but if you examine it from the perspective of Angular served through a Rails HAML view there are several issues with this piece of code:

It inadvertently piggybacks on it's parent's scope, blurring the lines between where it's function start and ends with that of it's parent.

It assumes there are magic handlers defined (presumably by OverlayController) that will be there for it's button components to call that will do something.

It exposes it's internal state externally by declaring behaviour bound to the external isOverlayShowing variable.

The immediate problem you can see here is that the class names that are designed to style the specific instance of the CSS component are being used to define behaviour which removes flexibility from our system. Most CSS folks would say there you should use IDs for attaching behaviour and classes for styling but in our case as we are trying to keep components reusable this is not really applicable as we may end up using ID's in multiple places on the page.

More Directives perhaps?

So classes couple style to functionality and ID's wont work when we have multiple components on a page, that leaves us with perhaps using more directives to handle functionality?

The Registry Pattern

A real solution to this problem would be to create a registry that registers elements with the given parent scope and finds those elements from that scope. This should work so we can define elements like this:

This works in some cases but reacts poorly to race conditions where we need the elements before the elements have been rendered and compiled. What about if we add some asynchronous callback magic so we can use the finder like this:

Looking at this view, we now don't need to care about the functionality that Angular is adding, although it is clear to see where those behavioural additions are. All we see from the perspective of the view are exactly all we should see: our styles, which are important in a view and the general structure of the HTML DOM which we can now manipulate safely without worrying about how that affects our behaviour we have received from Angular! :)

]]>So I have been on the system I have been using for almost 9 months now and only now, mainly as a result of laziness, have I finally gotten around to get git autocomplete going even though it is embarrassingly simple.

]]>http://rudiyardley.com/git-autocomplete/bd96b88a-03a7-4da2-8385-9a28b1b68945Thu, 15 Jan 2015 06:00:00 GMTSo I have been on the system I have been using for almost 9 months now and only now, mainly as a result of laziness, have I finally gotten around to get git autocomplete going even though it is embarrassingly simple.

If you then close and reopen your terminal, you can simply type git chec and press tab, and you will get git checkout. Not only that but all your branches and changed files will autocomplete. It really is rather awesome and it makes my life better enough that I needed to write a post about it!

]]>After messing around quite a bit with Docker over the last few months trying to work out how to deploy a client Spree/rails app to a new VPS, I stumbled upon Adam Wiggins' 12 Factor App manifesto and realised that I had by virtue of simply using a combination]]>http://rudiyardley.com/12-factor-apps/4e841d0e-1570-4971-bf13-f8f31194a858Wed, 14 Jan 2015 08:05:44 GMTAfter messing around quite a bit with Docker over the last few months trying to work out how to deploy a client Spree/rails app to a new VPS, I stumbled upon Adam Wiggins' 12 Factor App manifesto and realised that I had by virtue of simply using a combination of both Docker and Rails had effectively put together a 12 Factor App.

Here is a presentation I did on the structure of 12 factor apps and how they relate to Rails and Docker. I have a part II planned on the underlying Software Engineering Principles and Patterns of 12 Factor Apps so stay tuned.

[slideshare id=43494972&w=697&h=515&sc=no]

]]>This is an example of a neat way of handling classes in ECMAScript 5. ECMAScript 6 provides a way to handle classes natively which would thankfully make this trick redundant.

JavaScript is an object based prototypal language which raises some difficulties and peculiarities for how to write and design object

]]>http://rudiyardley.com/object-oriented-javascript/31e138fc-227b-4837-ba1f-5b580003d3c6Sun, 27 Apr 2014 09:57:00 GMTThis is an example of a neat way of handling classes in ECMAScript 5. ECMAScript 6 provides a way to handle classes natively which would thankfully make this trick redundant.

JavaScript is an object based prototypal language which raises some difficulties and peculiarities for how to write and design object oriented systems. Here is a basic treatment that discusses my preferred way to handle objects, pseudo-classes and hierarchies in JavaScript. My approach starts with the classic function prototypal style then adding some simple clear meta-programming we can use a much more declarative object style. This simple syntax makes working with JavaScript classes just a little bit sweeter have a peek:

Class style object instantiation with prototype

The defacto standard for managing constructor based object inheritance.

Having to add dangling prototype assignments outside of constructors is a scattered way of dealing conceptually with what should be a unified entity, also, if you want to hide data privately one would have to use the parent scope which could be shared across objects limiting the point of hiding such information. Lets try to pull it all together with some simple syntactic sugar.

One better way to declare classes in JavaScript

The benefits of using this style of object programming are that the object is encapsulated within its own function scope whilst at the same time having a clear constructor as well as providing a place for declaring private closure variables that can act as member variables.

Conculsion

So presented here is a lighter and library free way to define classes in JavaScript. Hopefully with the advent of ES6 in the coming years, having to write your own meta-constructs like this for something as simple as object oriented programming will not be necessary. Now with tools such as Traceur becoming a standard option on bundlers such as webpack, this sort of thing could soon become a thing of the past but until then, and if you are using a system that is built without a transpiler, this is a nice lightweight way to get around some of the minor issues with Object Oriented JavaScript.

]]>So today I am starting a new technical blog. I am hoping to present all the wonderful new technologies emerging around the JS and Rails communities and have a discussion about them analysing pitfalls and successes as well as share techniques and wisdom I gain over the course of the]]>http://rudiyardley.com/welcome/a7e67e40-e5ed-4666-89e5-01ede3860831Sun, 27 Apr 2014 05:03:24 GMTSo today I am starting a new technical blog. I am hoping to present all the wonderful new technologies emerging around the JS and Rails communities and have a discussion about them analysing pitfalls and successes as well as share techniques and wisdom I gain over the course of the next few years. ]]>