DEV Community: Richard Wood

Playing with "with" in Elm

Richard Wood — Wed, 04 Sep 2019 11:55:35 +0000

Inspired by With* Functions in Elm by Charlie Koster I determined to bring in a set of 'with' functions into a recent work project.

Koster's example allows you to create a default button and then pipe to one or more modifiers rather than define the full record of modifiers each time.

From his code:

default "Small Call to Action" Msg
    |> makeSolid
    |> makeDisabled
    |> view

My code was in a worse state. For my calling functions I had unnamed parameters rather than an options record as a single parameter. These had grown as the application grew, to a point where it was wasn't always obvious what a parameter might be for.

singleCheckBox 
    editingUser.blocked 
    (ToUsers << ChangeBlock) 
    "login blocked" 
    False

Rather than separate out required parameters and retain them as regular parameters I decided for simplicity to put everything in the option parameter, to benefit from them all being named.

Then when I started to create the "with" statements I soon realised the number of "with" modifiers would blow out, yet a lot of what is needed is the same concept between input types.

So I decided to use the record modifying syntax that allows us to be generic. Now I can use the one "with" modifier for title, for example, across the different buttons and inputs that I have.

withTitle : String -> { a | title : String } -> { a | title : String }
withTitle value record =
    { record | title = value }

You may realise I do not have as much type safety going on as Koster did. His is a module just for a button and tied down to it. I have a module for a collection of different inputs. I'm not clear yet if I can retain the generic approach if I lock it down further.

I also read this exchange started by Thomas Kagan where the pros and cons of pipelines vs list of attributes are discussed.

I decided the list of attributes approach was more consistent with rest of my code. I also placed the options type definitions and default values in the context of each.

type alias InputOptions =
    { textContent : String
    , changeMsg : String -> Msg
    , placeholderText : String
    , title : String
    , titleNote : String
    , disable : Bool
    }

inputBox : List (InputOptions -> InputOptions) -> Element Msg
inputBox optionModifiers =
    let
        defaults =
            { textContent = ""
            , changeMsg = \_ -> Noop
            , placeholderText = ""
            , title = ""
            , titleNote = ""
            , disable = False
            }

        options =
            List.foldl
                identity
                defaults
                optionModifiers
    in
    ...

I applied this approach to all of input views that I have - both inputs as well as views that present collections of inputs. I've ended up with a list of 20 "with" modififiers I can use generically.

Now my calls to inputs look great

standardButton
    [ withButtonMsg (ToUsers (ConfirmDeleteUser userId))
    , withTitle "Delete Permanently"
    , withColor color.red
    ]

I can tick off that the code is more readable excepting the addition of the foldl statements. And above all now only the parameters beyond default values are passed and they are all named.

Type Wars, TDD and Elm

Richard Wood — Tue, 03 Sep 2019 10:23:53 +0000

Should we TDD in statically typed languages, even in Elm?

Yesterday I offered an opinion on Bob Martin's video The Future of Programming. The comments went off on a tangent and ended up with the attention of a moderator. In amongst that I learned there had been a kerfluffle online earlier about another Bob Martin missive - Type Wars.

Ok, so bear with me.

The crux of that debate is the characterisaton of innovation in language as a battle of ideas that began between those that want no types and liked C and those that want types and perhaps if they are old enough liked Pascal, or more lately Java and C#. It seems in his world you had to choose your camp and defend it ... unless you switched sides.

Back to reality

What I do like in the article is what matches my experience, that in the Ruby world with dynamic typing the ultimate is to do TDD. Unit tests rule and drive you crazy. However over in the static typing C# world people seem happy with a lot of after-the-fact unit test creation. Although that can then become a drudgry task for some and risks not being done well.

I don't see a battlefront at all. It simply makes sense that if you are not getting help from a compiler and perhaps write all your software in a code editor, as many Ruby folk do, then you you need to have as comprehensive as possible unit tests. Hence TDD, which by definition gives you a certain amount of unit tests for every function.

If you are getting shit loads of help from your compiler and your IDE, as you do in C# and Visual Studio, and even more so in Elm, then you will need less from your unit tests.

I still admire those that TDD in languages such as C# but the reality I have seen is that very few judge it necessary to acquire those skills.

That said I came across this debate about a library in strictly typed Elm targetted at TDD. And this also.

Sidetrack

For those outside of the Elm community the contents of that debate might seem odd. Someone who loves TDD wants to have a testing library focused on it and puts in his own efforts to create it. The supporters of an existing testing library aren't happy it seems because it breaks a community desire to focus efforts for maximum impact.

I have long been bemused by those in the Elm community that push that there should only be one library per language function. Nothing wrong though with throwing some good questions in to really test if someone knows what is around and is committed!

The bottom line though is that if someone wants to go and write a library that overlaps another then that's their perogative. If it gets community support then let it be on the library's merits. You can just imagine whose sides people would have been on when Einstein came up with his reletavity ideas.

I hope what I saw at Elm Europe 2019 heralds a more open thinking future. Two groups forking the compiler and a leader of the community kicking off his own language development.

Create a whole new thing - Great! You may cause a revolution or you may influence evolution of the existing dominant tool.

Back to TDD

Now, looking at the idea of a testing library for Elm focused on TDD. As someone who has only dabbled in TDD in Ruby, the question of the value of TDD in Elm is what I am left with.

Elm, like Ruby, is a language that can just be loads of fun to program in, in quite a playful way. As well as being a solid choice for bigger projects, it is great for your own startup and for experiemental greenfield projects. A function may only last 10 minutes before you refactor things and it disappears. Elm also has the bonus of a compiler that really helps you along to write your code and refactor.

TDD would seem to be more suitable when the thing you are building is well defined. You can nail down at the outset what you intend to create. Then it's quite a mechanical thing to write the code to meet the tests.

Is TDD though just the articulation of the process you are doing in your head anyway, slowed down? You have identified a need for a function, you have in your head what you want out of that function and you write the function.

Some people advocate writing code incrementally, which is a form of transitory testing as you create using dummy values and function calls. Is that the same process again from an other view?

Let's assume you end up writing all your tests anyway. What I want to know is. Does doing TDD, particularly with statically typed languages, take some of the immediacy and fun out of the process? Or once you are good at it, is it a seamless experience with the same level of enjoyment?

The Future of Programming - Rejected!

Richard Wood — Mon, 02 Sep 2019 08:08:52 +0000

Much admired software guru "Uncle" Bob Martin wants to take away all our fun and make us into responsible "disciplined" programmers.

I watched his talk The Future of Programming recently. His beef is that, if we carry on as we are, the authorities will regulate us. So we need to regulate ourselves, make software programming a profession, create and enforce standards, etc etc.

Coming from the 70s dark ages where perhaps most projects were for military, space exploration, or some big industry project you can speculate why he may think this way.

In essense coding requires mathematical nous, and a high level of discipline that older programmers had because they became programmers later in life. Now there are lots of youngsters who don't have the discipline yet and what we do can kill people.

Lol what low percentage of us actually work on software that could end up killing someone. FFS.

Of course there are airplane systems, factory controls, social media tools that encourage suicides and terrorism, etc etc.

However, most of us work in website development helping businesses look good and be more efficient. Even a fintech solution shuffling large amounts of money around needs to be kept in perspective. There are critical parts to the code where errors could make people bankcrupt and there are soft parts that are just about winning and keeping customers with a great UI.

On the other hand a modern take on coding is that it is like writing and should be taught as such in primary school. Some people literally think anyone can do it and everyone should be able to. The bootcamp I went through - New Zealand's Dev Academy - pretty much had this attitude. In retrospect I think they overstate it.

So we have two extremes and the problem is not that we all need to be regulated. Would you force a poet to use a particular style? Does every novel have to have 3 dramatic stages? No. Should an aircraft manual be structured, detailed and constantly updated? Yes.

The issue is that some software development needs more rigor and oversight than others. Where there is development of critical systems for likes of spacecraft and airlines then bring on the regulation. Even if it means people there have to program in last decades' languages when a modern language would be better. There are plenty of people who like the old languages and have the experience to make that code bulletproof.

Segregate that lot and leave the rest of us in peace. We are having fun creatively developing frameworks, languages and solutions at dramatic pace.

There's this idea that young developers are reinventing the wheel all the time because they dont understand enough yet. Is this a case of aging developers who may want to maintain their position in a fantasy heirachy. News flash - very few people care, they are having a ball.

Young people are experimenting, having fun, finding multitudes of ways to express themselves and solve problems with code. The best learning happens through play!

Ok. Let's face it, the amount of effort put into JS in recent years was stupid and unproductive. We ended up with the dueling nightmares of React and Angular. Node was like the warm up performance. We also got a crazy amount of other backend language options. It's all driven a hugely inefficent industy in learning and recruitment.

But for all that, this creative surge got people excited, interested and in my view it's all very healthy. The ease with which people could and can pump out libraries, frameworks and languages has democratised language development.

The lead has been well and truely wrested from the cohort who kicked off this industry so many years ago. Yes they should be respected for it, despite writing huge boring books about subjects such has how to keep your code clean and overcome the defiencies of OO. :)

Out of an apparently ridiculous situation will come better things and like many I'm putting a lot of faith in functional programming. Go on, check out Elm and Elixir if you haven't already. There is huge opportunty for evolution and revolution. Enough to keep young programmers excited for decades to come, and with a lot of the discipline built in!

Otherwise, the populace don't need nostalga buffs telling us what to do, warning that the sky is falling, and taking away our fun.

Keeping it simple beyond a basic Elm app

Richard Wood — Thu, 18 Jul 2019 21:11:38 +0000

When you want to go beyond a basic Elm code base people will usually point you to Richard Feldman’s elm-spa-example.

Unless you are confident you are heading for a multipage, feature-rich extravaganza then this is overkill.

Yes, it proves that in Elm you actually can break things into subcomponents, delegating models, messages and subscriptions, which in no way means you should.

On the other hand, it's also been said that you can just put everything in one file with a huge update function with hundreds of lines. Um. Seriously, you probably don’t want to be waiting for that to scroll or end up jumping to specific meaningless line numbers.

Recently I had a mid-size web app to start building so I sought to navigate a middle path. Starting with some basic principles.

Keep it simple - future maintenance depends on it.
Minimise meaningless abstractions and patterns - code that doesn't do what the app is trying to do wastes everyone's time.
Don't fight The Elm Architecture - update function changes model is changed and calls commands. Model changes are reflected in views. View events, command results, and subscriptions lead to more updates. It's a virtuous and relatively tidy one-way circle.
Avoid nesting. Keep the single source of truth model as flat as possible. Remember that all events flow through the main update even if delegated.
Don't make it difficult for components to interact. A web app will generate events in one corner that lead to model changes and commands affecting other parts of the app. Subviews will need access to the top level and other component's data.
Make it easy to find relevant code.

I began with create-elm-app with a one file solution, then upgraded to Browser.application when I needed access to the Url.

When I felt the update function was getting a bit scrolly and I had a user editing section that was burgeoning I moved that into its own file. It was at this point that I had to decide how far to go with delegation.

Interestingly, and something I’ve found previously, is that it is pretty easy to get into a situation where you need to call back and forth to your main file for type and message definitions - leading to circular references.

I’ve found in the past that this can be knocked on the head by putting all types in a file called Types, all msgs in a file called Msgs and common functions in a file called Helpers or a file called CommonViews accordingly.

So I went ahead with this refactor. This worked in tune with not going crazy on delegation. What we are trying to avoid is stuff that makes you think too hard, like this from elm-spa-example:

updateWith : (subModel -> Model) -> (subMsg -> Msg) -> Model -> ( subModel, Cmd subMsg ) -> ( Model, Cmd Msg )
updateWith toModel toMsg model ( subModel, subCmd ) =
    ( toModel subModel
    , Cmd.map toMsg subCmd
    )

Noone should have to read that!

In a nutshell I went with a delagation for the update function but not for anything else.

So in the main update:

case msg of
    ----COMPONENT MESSAGES----
    ToEnv envMsg ->
        Env.update envMsg model

    ToUsers userMsg ->
        Users.update userMsg model
        ...

    ----TOP LEVEL MESSAGES----
        ...

The wrapped messages for the components do often mean I am doing component composition (<<) to reference them.

In the Types file the main model definition is broken into component sections by using comment separators.

This helps keeps a lid on nesting and keeps the single source of truth reality front-of-mind.

It means also one equivalent init function, albeit referencing empty component-specific records, which for now I am holding in their respective component files.

type alias Model =
    { window : Window
    , messageToUser : Maybe String
    , env : Env
    , initialUrl : Url
    , navKey : Key
    ...

    -- User
    , users : List User
    , userSearchQuery : String
    ...

For the Msgs file there is a main message type for the main file that includes the component wrappers, and separate message types for each of the components.

type Msg
    = ResizeDevice Int Int
    | ToEnv EnvMsg
    | ToUsers UserMsg
    ...

type EnvMsg
    = GetEnv
    | EnvResult (Result Http.Error ConfigEnv)
    ...

type UserMsg
    = ClearSearchUsers
    | SearchUsers
    ...

I could have put component messages in with the rest of the component. However it has been useful to keep all possible messages in one view as far as possible.

The net effect of this is that the main has a very clean update function showing the structure of the application, without meaningless absractions.

The component file have their own update function that works off their own message type and comes back to the single source of truth model either through top level of any component messages.

update : UserMsg -> Model -> ( Model, Cmd Msg )
update userMsg model =
    case userMsg of
        SearchUsers ->
        ...

There is a little bit of nesting access needed in the component but only to one level so it’s manageable.

The component files also hold the related views for those components.

I haven’t found a reason yet in my app for delegating subscriptions, perhaps because I don’t have many yet. I also am not doing much with routing yet.

Otherwise, overall I am very pleased with the result for a small to mid-size app. There is a minimisation of scaffolding. It has been very easy to be able to find, add to and refactor code.

Elm Europe 2019 - Elm and GraphQL heavenly match

Richard Wood — Wed, 26 Jun 2019 19:11:33 +0000

Today I attended a full day workshop on Elm-GraphQL at Elm Europe lead by the package’s author Dillon Kearns.

There were 10 attendees, all with a variety of interests ranging from learning more about the Elm ecosystem generally to adding to their skills for work or home projects. A few including myself were working or had worked in environments with GraphQL but not Elm, so a great opportunity to bring two worlds together.

And what music these two worlds together bring. GraphQL is effectively an enhanced type system that sits between your client front end and your back end data. It allows you to send nested queries without having to set up or distort a REST endpoint for every variation. It’s easy to be specific with what you want from the backend and not ‘overfetch’ or ‘underfetch’ as is easy to do using REST.

Instead you query using object style definitions and set up ‘resolvers’ for every type of data you may want to call. If a type of data has another type of data within it then a resolver is called for the inner data and so on. On the flip side this may mean more individual calls to your database, which may be a problem depending on your application needs and the sophistication of the back end GraphQL server in generating SQL calls.

This whole GraphQL thing came out of Facebook and you can intuitively see how it would have solved a lot of their 'graph' access challenges in pulling together data in different views from different people and types of records. These days GraphQL is used by many companies including GitHub, Shopify and Twitter.

Having a declared schema, introspection, and documentation in whatever GraphQL implementation is server-side gave the opportunity for Dillon to create a code generation tool that gives you the equivalent types and decoders in Elm. That is paired with the Elm package to give a seamless way to retrieve data. So no more doing your own decoders. Dillon also has a related tool for Typescript and Elm.

What this means is you are getting pre-made Elm modules that allow you to build queries that are fully typed and you know will work if they compile (if your GraphQL backend is full-proof of course). All the benefits of the Elm Compiler, edged into the back end.

So, a graphql query just looks like a JS or JSON object but just the keys of the data you want, nested as far as you want. A get query returns the object with the values included.

A graphql mutation query can also return a query but the main point of course is to change particular fields. There is also a subscription query for setting up data change notifications that may typically feedback through web sockets. GraphQL is a transport agnostic spec.

We covered a lot of detail around nullable fields, scalar fields, ENUMs, lists and more. Then we got onto exercises that introduced us to how this all looks in Elm. If you compare side-to-side it’s a little bit verbose and daunting, but once you start playing with it you can see the power.

Elm-GraphQL doesn’t just imitate what you can do in a regular GraphQl client. Dillon described it as operating at a higher abstraction level, because of what Elm itself adds to the equation.

And there's what can be brought back to the compiler from the introspection of the GraphQL server implementation. Being able to get Elm compile errors for invalid queries at compile time is a boon. Having docs in your editor, just being able to write your queries as Elm language not as magic strings.

Dillon also had a focus on the process of writing code that was like a bonus gift in the workshop. For example writing small pieces at a time that compile and work and using dummy values along the way to reduce cognitive load.

Also encouraging us to experiment with pipeline patterns and see how it affected error messages. In Elm-GraphQL you build up your query ‘selection set’ by specifying fields in a SelectionSet.mapN function call or by building a pipeline starting with SelectionSet.succeed. This approach and the tradeoffs will be familiar to some.

I’ve purposefully left code out of this blog post as it would get deep very quickly. I don’t want you to think it’s all a walk in the park. There is a learning curve and it helps if you are confident in the range of Elm language features at the outset.

Even with the smooth code generation in Elm-GraphQL the reality is that two worlds are coming together. You can still find yourself staring at something blankly not sure how it relates to the simplicity of an Graph-QL object. You will import the code that is generated and you need to understand what is in those files. The compiler will help you a lot but sometimes the error messages will flummox.

Nevertheless we could see with the fluidity that Dillon moved around his examples that it is just practice - and in parallel you should get fully up to speed on things like opaque and phantom types as these can help to understand things.

The ability to remove uncertainty is what this is all about, as Dillon has spent much time talking about previously. With the contracts that GraphQL enforces passed over to Elm you are able to have confidence that your queries if they compile will get you the data you want.

It is a pretty good feeling.

https://package.elm-lang.org/packages/dillonkearns/elm-graphql/

Immutability - something worth striving for

Richard Wood — Fri, 30 Nov 2018 09:29:56 +0000

When I worked in C# at PartsTrader I started to see the similarities between what Domain Driven Design is looking for and what Functional Programming does. Or rather what FP has to do to be able to be useful in the real world.

I currently develop in Javascript for one client and functional language Elm for another. I've previously worked for two .Net companies. One of them - PartsTrader - was dead keen on DDD.

So I'm talking about separating out pure functions from side effects. In DDD the idea is to circumscribe business logic, keeping all the IO and external interfaces outside the circle.

Whamo, when you look at a functional environment such as Elm, you have all the pure functions segregated away from the messy IO and external javascript functions.

The difference is that in Elm this split is mandatory. In DDD and object oriented languages it's a voluntary design decision with some serious book reading available to convince you that you are doing the right thing lol.

However, it still comes back to immutability. Functional programming gives you this off the bat. In non-functional languages it is still a great idea, but you have to choose to do it. The benefits are that your code is easier to debug as what goes in and comes out remains constant at every level.

In Elm the entire code is immutable - think of it as one big function that is called as needed. Anything side-effecty will be done by the runtime and then the function called again.

This has some interesting benefits. If you want to see what your programme is doing, just look at the big 'update' function that is at the bottom of this tree and anything it delegates it to. With the strict typing on top of that, if you make any changes that disrupt things you find out very quickly on compile, and the error messages just 'know' so much about what you are doing.

Which is not to disparage .Net's Visual Studio when using C#. It 'knows' a hell of a lot before you even get to compile thanks to the work that has gone into it over the years from some very smart people.

In non-functional languages it is also good practice to pass in any values that may change randomly so that you still have unit-testable functions - dependency injection. In Elm, functions that call side effects don't return things back into the code and so don't impact the return value. They go off to the runtime, which then returns values through the message update channel as if some magic fairy generated them.

Anyway, developing in Javascript is where the rubber hits the road for this discussion. On the one hand it is a functional language in that functions are first class and references to them can be passed around. On the other hand it is so loose that you can have side effects wherever you like. You really don't know with some functions what might come out the other end. Tightening that up requires a fair bit of overhead construction.

I am working on an old JS code base that I've largely converted to ES6. While I've brought in Webpack, I've shied away from introducing any of the new frameworks like React and Angular - both of which I have used before. I use a bit of native JSX as a short cut for templating forms and menus, but that's another story.

With ordinary JS you can still take a strategy of making things as immutable as possible. Again it means segregating out anything that is a side effect until your functions become pure.

In my case I'd like to start to reorganise the codebase so that, well, it looks more like an Elm structure with a tree of update logic updating a model and a set of view functions that simply reflect the changes in the model - all as pure as possible. I'm still working through how best to do that in combination with the heavy use of Mapbox and Leaflet in the app.

There are also times in the nitty gritty when imperative code in Javascript is just easier to understand and quicker to achieve, and being pragmatic is certainly a good quality. Perhaps best to leave a comment in such functions that they should not be extended into incorporating side effects and make sure not to pass anything external in.

I believe that immutability and segregation of side effects is one of the core goals worth striving for in software design. If it can't be achieved immediately it should at least be regarded as the preferred direction.

I am confident that by taking this approach something easier to read, maintain and add to will come of it.

Is coding easy?

Richard Wood — Fri, 12 Oct 2018 08:10:09 +0000

My eldest son asked me - is coding easy?

Where do you start. At the Dev Academy bootcamp they were adamant that just about anyone can give it a go. Yet I still think an ability to think logically, some mathematical nous and basic communication skills are essential.

I suspect their message was mainly to get people who had self-doubts over the sign-up line. Some people just don't realise what they can do and some of this can certainly also be taught.

If you can think logically and have a lot of patience then you can work through the hard-to-read documentation. If you can sit at a computer for hours. If you can create the right search online. If you can generalise off the examples that don't always match the difficult problem you face. Intuition helps immensely there too.

It can be easy if you don't have a constant need to interact with your colleagues - although working remotely mitigates this for me. If you enjoy that fully focused in-the-zone time when everything else disappears. If you enjoy solving puzzles and problems that you know must have a solution even if you just can't see it. That's part of the answer.

It can be easy. If it's something you've done a few times before. It's all relative to the difficulty of the problem you face and your familiarity with the tools you need to use. New and unknown have to be treated like exploring rather than doing.

It also depends on how tired you are and whether you are really doing in life what you want to do.

It will be easier if you surround yourself with people who are better at it than you. If you work in companies with big teams. With people who want to help you. If you love to hang out on technical forums and don't mind posting dumb questions. If you are a good person and look after your relationships with the people who are answering your questions.

It will be easier if you are immune to the sort of technical criticism that suggests you are the dumbest person in the room because you don't quite get something yet, when that is more about the other person's lack of communications skills or dumb ego. The reality is everyone is always learning.

It will be easier if you like to go to meet-ups with like-minded people and like pizza. If you like to go to conferences and can actually absorb what is being said. Or you love to watch tech videos or work through tutorials online in your spare time.

It will be easier if what you are working on actually inspires, your team is fun, and your boss doesn't suck.

And over time yes the technical side gets easier as you learn the tools. As you come across the same concepts in different guises and odd things you learnt on one job become useful in another.

It gets easier as you come to understand the parts of the job you are good at. When you learn to recognise when you need to go for help vs banging you head against a wall of unknowns.

So yes for me, after four years, while there is the occasional day when it seems impossible, it is otherwise easy.

For you I don't know.

Elm Europe 2018 - attending Richard Feldman’s workshop

Richard Wood — Mon, 09 Jul 2018 11:11:14 +0000

When I booked for Elm Europe I gave myself a day to recover from the early morning flights - Cyprus to Belgrade, Belgrade to Paris. Then a day for sightseeing before the conference began...

Then, dammit, Richard Feldman offered a workshop on my sightseeing day! It wasn’t exactly cheap and it got me thinking about the value of workshops vs conference presentations. It must differ for different people. For a start, it would depend on how best you learn, as well as how much the cost eats into your income for the year.

It’s important as a web developer to hone in on how you learn. We are faced with continuous change. You may for example learn on the job, through tutorials, books, from colleagues, workshops or combinations.

Some may be able to sit through two days of presentations and learn a lot from them. Personally, I am easily put to sleep. I need to engage and workshops provide exactly that, as do tutorials.

It’s also about how important learning is for you at a conference. Is meeting people more important? Is hearing a diversity of ideas more valuable? I love to meet people and am also very aware that both friendships and work opportunities may come from such contacts.

However, as a remote worker I find learning is top priority. Without colleagues to learn off face-to-face in the office, you have to take the opportunity to pick up whatever you can. Workshops may provide the friendships and learning.

Half a dozen people attended this workshop, which was good for me, not so good I suspect for the presenter and organizers. I recommend fine tuning the price to increase numbers. The sweat spot was probably at a lower price with more people and up to a dozen would still be very manageable.

The content was targeted beyond beginner level. This is where a lot of people would now be looking and was perfect for me. The direction was informal and fluid according to attendees needs. In the morning it was more of a review of things I already new. Even that is valuable, as it reinforces.

The afternoon was full of things I didn’t know about and hence I came out of the workshop suspecting I had received long term value and may well have got my money’s worth. I’d like to see more workshops, altering the balance of what is regarded as the main event.

The rest of the Elm Europe was also good though. There were a number of presentations that educated and/or entertained. I’d rate Feldman’s presentation on the second day as the best as yet again it was practical applicable material.

So what did I learn about at the workshop?

Some notes:
Better to decode initial data coming through flags rather than let it be automatically turned into records - I guess this is about type safety.

Use intermediate representations rather than change your model to match incoming JSON records - you don’t want your code determined by something in JS or other land not designed necessarily for your situation.

Nested model updates are a sign that something is wrong - split it out and work with something smaller. Although it’s not nested vs flat, it’s situational for when there is something you can work with.

Move functions to the top level rather than in a let-in block - this is about being explicit about the dependencies. In a let-in block you have access to all the parameters of the enclosing function. The exception is when you are actually going to use most of those parameters.

Phantom types - adding a type definition you don’t use - can be useful for catching certain compile time errors - I’d need to review this again to recall what that looks like in practice.

Trick for unwrapping - avoid case statements for single option union types by using pattern match:
e.g.

display : Value a -> Style
display (Value str) = 
    makeStyle (“display: “ ++ str)

There was something about how when making a union of types the more open type results. This was a little above my understanding so I’ll just file it away until I come across it next. Lol.

When parameters appear at the end of both sides of a function definition you can remove them, but don’t, as it affects readability.

Ports - use one set of ports for everything;
e.g.

port sendToD3 : Value -> Cmd msg
port receiveFromD3 : (Value -> msg) -> Sub msg

This is a concept that has gained traction but not with everyone. I had some side conversations about it and there is concern that it is less type safe for example.

Ports - who should own the state of a library? JS should. Elm doesn’t change it. If you want to change it, send a msg out to JS to change it, and it can send a message back to Elm to change it’s model. If choosing where to draw the line between JS and Elm, default to a minimum interface between them.

Then we got onto some meaty stuff around JS interop - getting beyond using ports:

One way is Custom Elements, which is very useful when wanting to manipulate stuff in the DOM - think View as the interface rather than Update. Basically a custom element can be produced by putting a ‘-’ in a node name: Html.node “rtfeldman-div” [] []
generates
Custom Elements need polyfills for non-Chrome browsers.
Another way is to use custom events on their own. Register the event in JS and pick up from Elm using ‘on’ under Html.Events.

Then there was a review of Html.Keyed and Html.Lazy. I hadn’t used these before so it was all good stuff. Keyed is uniquely identifying rows for for when you want to make adjustments without Elm redrawing significant portions of the DOM. React has something similiar. Lazy should apparently only be used when you experience a runtime performance issue. It prevents reevaluating view functions where the parameters and result have already been calculated.

Finally we had a look at parsing. This a pretty powerful tool for validation or other applications and worth knowing about.

Note that Feldman is preparing a new course for Front End Masters that will go beyond beginner level and incorporate some of the stuff we talked about at the workshop. I’ve no doubt I’ll take that as well.

Cloudinary uploads direct from Elm

Richard Wood — Fri, 04 May 2018 11:37:34 +0000

If you need to store your images on a third party server, you may well have considered Cloudinary - https://cloudinary.com/ . It has a raft of cool image management features that take away a lot of the hassles of dealing with images in your application.

Cloudinary has support for a variety of languages but as anticipated nothing explicit for Elm.

But no problem as there is elm-cloudinary - http://package.elm-lang.org/packages/ghivert/elm-cloudinary/latest

And the good news is it appears to work out-of-the-box. There is some JS code you need to put into your index.js and then follow the example to include the necessary fields, msgs and update handling.

Now, I didn't actually have it working at that point, since our requirement is to upload unsigned uploads direct from the browser. This is a feature that Cloudinary supports but it looks like it came out after elm-cloudinary being released.

So, time to hack the cloudinary.elm file. What I discovered was that simply a different settings file was needed.

The existing settings file is:

type alias Settings =
    { username : String
    , apiKey : String
    , timestamp : Int
    , signature : String
    }

For unsigned calls these need to be replaced with:

type alias SettingsUnsigned =
    { username : String
    , uploadPreset : String
    }

You get the uploadPreset string from the Cloudinary management portal.

Rather than have one overall settings record and fill in different fields, the settings have to change because if we continue to include the authorisation fields in the original settings then Cloudinary won't accept the upload.

What I did is take each of the features - uploadPhoto and trackUploadPhoto - and create unsigned alternatives using the unsigned settings. This is a cheap approach that means I haven't disrupted the signed features if I need to use them later. Intention will be that when I am confident this is working I'll file a pull request back to the original elm-cloudinary author.

I have tried experimenting with whether union types or some other construct might provide for the original function set and just vary the settings. Haven't been able to do that yet without breaking changes to the API. Keen to hear if anyone has ideas for this.

Attempt to track progress

In the meantime the other obstacle I came across was in the trackUploadPhoto feature, or in my case I created trackUploadPhotoUnsigned. This arose because we were uploading a Cloudinary image but without a progress indicator.

The elm-cloudinary uses Elm's Http.Progress and looking in the console at the network responses showed that the Progress.track subscription was only responding that it is done, but not sending 'Some' notifications along the way.

Exploring this I found the following very helpful post request example: https://github.com/gdotdesign/elm-ui-examples/blob/master/file-upload-progress/source/Main.elm

I tried implementing a bit of this, even making my own custom request and to cut a long story short I found that if I sent the file to a dead drop such as "https://httpbin.org/post" instead of Cloudinary's url then I got back the Progress Some notifications.

Further seeking help online I have so far concluded that this is to do in the Cloudinary case with the request using 'chunking' in transfer-encoding, which results in content-length not being returned in the request response. Without that, progress cannot be determined.

Cloudinary provides progress capability in its JS widgets and I've asked them if there is another way to get this information. Any suggestions in this area are welcome as I'm clearly still learning about the intricacies of http requests and responses.

Geolocation in an Elm web application

Richard Wood — Mon, 30 Apr 2018 07:20:09 +0000

Getting location for your web application comes down to basing it on an IP address or using the HTML5 geolocation provided through your browser.

In the IP address case the location information may come from the registration addresses of the IP addresses amongst other sources.

With the browser approach it will depend whether your device has GPS or not. If so then it can use that system, otherwise it may also look up third party databases of IP addresses. One example is the data collected by Google's StreetView surveys.

Getting IP address sourced location data using Elm is easy-as. First find a source by googling for IP address location data. I found this list to be very useful: (https://ahmadawais.com/best-api-geolocating-an-ip-address/)

Then you want to send off an Http.get request. For example:

Set up the get, where decodeData uses the original method or the pipeline decoder style and YourData is a type alias reflecting the format of the data.

getData = 
    Http.get "https://api.ipdata.co/?format=json" decodeData

decodeData =
    decode YourData
        |> required "latitude" Json.Decode.float
        |> required "longitude" Json.Decode.float

Do the send using the Http.send or RemoteData.send approach. In this case LoadData is a Msg (Result Http.Error YourData) you've defined to handle the response.

sendData =
    Http.send LoadData getData

If you want to use the HTML5 solution built into your browser then there is an Elm module for that - Geolocation.elm -http://package.elm-lang.org/packages/elm-lang/geolocation/1.0.2/Geolocation

In the simplest case you may fire off the Cmd msg from an Update function where FoundLocation will be another update function that interprets the results:

GetLocation ->  
            ( model, Task.attempt FoundLocation Geolocation.now )

FoundLocation -> 
    case location of
           Err error ->
               ... do a case match on the various error types

           Ok location ->
               ... access location.latitude, location.longitude and any other data you need

Note the user will be asked to confirm that it is okay to share location information.

You may also want your app to be told when the user moves. You can set up an Elm subscription, which will call a specified update function - eg MoveLocation - when there is a change, with a Location type parameter.

subscriptions : Location -> Sub Msg
subscriptions location =
    Sub.batch
        [ Geolocation.changes MoveLocation ]

Whether you need to store state on your model will depend on your application. If so then at the beginning you won't know location so you will need to store location as a Maybe field and incorporate handling for this.

Into remote software development

Richard Wood — Tue, 24 Apr 2018 08:50:11 +0000

It's almost a year since I decided to remain in Europe and I left one of the best jobs I ever had, as a software developer at PartsTrader Markets in New Zealand. If you live in Wellington or want to move there and are a software developer then check them out.

I've always hated corporate culture (aka 'preferred a high level of autonomy') and one of the drivers for me to get back into software development was the opportunity to work in the flatter structure of agile teams or go remote working.

So then the shift from a great agile environment to working from home/coffee shops may seem a big jump on the surface, but behind the scenes both deliver to me a feeling that you can get on with the work intensely and so long as you are delivering progress at the end of the day then it's a good feeling all round.

That's a pun by the way, because as a remote contractor I literally do tend to deliver code at the end of the day. I find that's best for communication, ensuring that you are on the right track and keeping your code on track with others.

The first few months looking for work were hard. I had three years full stack experience in C# and JS but what you really need is about five and JS frameworks are what is in demand.

In Europe also companies got burned with outsourcing and are very careful about remote workers. In the UK especially the term usually just means you can work somewhere else in the UK and they want you to come to the office regularly.

So I've had more luck from New Zealand and the US and the time difference can actually be a positive.

My first contract I did 40 hours a week for a US startup and it went for five months. It was originally going to be an Elm contract but it turned to Javascript. I learned React and GraphQL along the way and gained a lot of confidence in what I could solve on my own.

Unfortunately that work dried up and I needed to get back out looking. Since then I've picked up a Javascript contract from New Zealand and an Elm contract from the US. As I've gone along I've adjusted my rates but keeping them very reasonable as I regard myself as very much still learning the remote ropes. I've found having two part time contracts is also good.

I've seen companies trying to do the full agile team work virtually. I'm yet to be convinced that the structures that work in an office are appropriate or necessary remotely. If you want to work remotely you probably don't want to wake up at 3am to attend stand-ups and retros. Perhaps at some point I'll get some experience with one of those firms and see first hand.

In the meantime my focus is on balancing learning with earning. If I can see I will need particular knowledge then I make sure I have reading to do and tutorials where it is a bigger challenge. Part of getting back into blogging for me is to improve the learning I do by writing tech blog posts, which I've started under the banner ElmUpdate - https://dev.to/elmupdate

On top of that is avoiding isolation. Getting more engaged with the online community and getting to conferences - but making sure they are the right relevant ones. There's a lot of fluff being presented at tech conferences these days so it can be better to go to the workshops even if it is a big cost.

Final thought is around hours. 8 hour days in an office is fine. However, when you work remotely with no distractions that is an intense day. The cliche that 8 hours in an office is really 6 at best comes to mind.

I find software development addictive so doing 8 or 10 hours is not uncommon and I don't think that will change. However by that point you are suffering from a certain type of stress, not thinking straight, and you are probably not going to make the most of the evening non-work time as you will be mentally recovering.

Better to break up the day. Start with some learning, take a decent lunch break, do a blog post. Then you can do some quality coding - build your self-worth and reputation and not your sleep deprivation.

That's me for today. Until next time...

Implementing Elm Toasts

Richard Wood — Tue, 24 Apr 2018 07:29:19 +0000

When you want to send briefly displayed messages to the user of your web application, Toasts are a cool way to do it. You know those little boxes that show up on the side and disappear after a while.

Without anything in place so far to display errors or confirm activity I went hunting for what Elm had to offer.

There weren't a lot of offerings, but Toasty (http://package.elm-lang.org/packages/pablen/toasty/1.0.4/Toasty) looked like it had some good customisation capability and the demo certainly looked the part.

In my ideal world I'd install the package, edit a config file and start calling the module. Oops, that sounds like Javascript...

In this case there was stuff to add to the Model, initial model, a type alias, an update branch, and view stuff. I don't know if this is the price of type safety, or how possible it is to make Elm modules more independent. I'm just grateful people are writing these libraries at all.

AS STEP 1 - I recommend just following the instructions on that part of it.

At about this point and after playing around with Toasty.config things weren't working for me in that I was getting text showing on the screen that disappeared - good - but no box around it - bad.

Usually I skim read things and assume a 'work-out-of-the-box' mentality. Then when I hit problems I go back. In this case I re-read the opening bit which mentioned Toasty.Defaults. This gave me a starter Toast definition, which was handy but I wasn't otherwise much the wiser.

So time to read or at least look at the source code. Whamo there's an example App.elm in there that appears to be the code for the demo. I also found there Defaults.css and Toasty.Defaults, which you can customise. I needed to reposition my Toasts and change the widths for example.

AS STEP 2 - Bring Defaults.css and Toasty.Defaults into the app and customize to your needs. Then make sure all your references to myConfig are to Toasty.Defaults.config

This provided the missing pieces I needed to get it up and running.

Now I only had one issue remaining. I really wanted a minimum calling api. The site was suggesting putting this on the end of update functions:

|> Toasty.addToast myConfig ToastyMsg (MyToast "Entity successfully created!")

I liked the idea of feeding from update functions but there is no way I'm going to litter the code with lots of those.

The App.elm example had another version of addToast that simplified things to:

|> addToast (Toasty.Defaults.Success "Allright!" "Thing successfully updated")

I really just wanted to cover 90% of usage with something like:

|> doToast Toasty.Defaults.Success "Success" "You did it"

This can be achieved by adding a helper function that assumes the config file and Update message names:

doToast toast title message = 
    Toasty.addToast 
        Toasty.Defaults.config 
        ToastyMsg (toast title message)

or what I really wanted was:

|> doToast "Success" "You did it!"

So (purists please avert your eyes):

doToast : String -> String -> ( Model, Cmd Msg ) -> ( Model, Cmd Msg )
doToast title message =

    let
        toast = case title of 
            "Success" -> 
                Toasty.Defaults.Success title message
            "Error" -> 
                Toasty.Defaults.Error title message
            "Warning" -> 
                Toasty.Defaults.Warning title message
            _ -> 
                Toasty.Defaults.Success title message
    in

    Toasty.addToast 
        Toasty.Defaults.config 
        ToastyMsg toast

AS STEP 3. Make your own helper(s) that keep it simple and flexible for you. For example you may want to specify the length of time each toast displays for. That's just one of the config options you have with Toasty that I haven't covered here.

In summary: A very useful and flexible module that in the scheme of things did not take long to get up and running.