walterra

I develop data visualizations. This is my personal blog. More about me.

Posts filed under ‘Code’

Mini Modules

29. März 2016

My very personal opinion and 2 eurocents on the discussions surrounding the npm issues and the left-pad project: This post is not so much about the technological and social implications of the issues npm and the open source projects which had left-pad as a dependency faced. This is more about what I think regarding small/mini modules and the ecosystem which evolved around them. Personally, I really don’t care how many lines of code a module has. If it solves a need for someone else than myself, why not publish a single useful line of code as a module?

I think when discussing this, one has to take the whole ecosystem and it’s implications into account, not just the language itself. Unlike other languages which offer a unified VM or a supported runtime for your host system, JavaScript is strongly tied to the web and the runtimes provided by different browsers. There are so many interpreters/compilers/environments where JavaScript needs to work. It’s in a web developer’s DNA to work around the quirks and weird behaviour of different environments and solve cross browser issues. That’s why everyone was so fond of libraries like Prototype, jQuery, lodash and others. Their success is one part the patterns and ease of use they provide, but of course because they freed you from the one major pain when debugging web development issues which are of course the cross browser issues. And in recent years this isn’t even so much about the quirks of the major desktop browsers anymore. Think of all the mobile engines, think of the PlayStation browser, think of the poor guys who decided to spend their time developing websites with support for Google Glass.

The rise of mini modules in JavaScript stems from this: When you create code using JavaScript, a certain insecurity will remain if what you did will work everywhere in every kind of runtime that is out there. So even if you could of course implement little helpers like left-pad yourself easily, it’s hard and cumbersome to battle-test it under all kinds of circumstances.

This insecurity is the reason why I’m thankful as a developer to use a module which is hopefully well maintained by a bunch of other people, and more importantly used in the wild by others who will report and try to solve issues with the module (including myself in alternating the mentioned roles from time to time). This is how open source works for me and in that regard I don’t care if a module consists of a single or a hundred gazillion lines of code.

Keine Kommentare zu Mini Modules

An opinionated approach to have type safety in native JavaScript.

27. April 2015

Preface

I have to admit, I love JavaScript and do not completely grasp the bashing. It supports my style of thinking and prototyping. I like its flexibility, it gives me a lot of subjective freedom. But as Voltaire and others say, with great power comes great responsibility. By not forcing any models, certain styles or patterns on you there is a high probability of your project ending up in total spaghetti or even worse risotto code.

Therefore I’m a big fan of simple patterns and modularity. I don’t like monolithic frameworks which force you to use a certain structure or style of code. To understand what I like about simple patterns have a look at Bostock’s Towards Reusable Charts and Elliot on Inheritance in JavaScript. Over time I found a nice personal approach inspired by the mentioned ideas to structure code and work with OOP.

Originally coming from the PHP world (behave!) I like JavaScript being untyped/dynamically typed (whatever you prefer calling it). I understand that native statically typed languages might perform better. But I don’t like language fragmentation and I don’t understand why you would want to program in a different syntax or dialect if you’re „compiling“ to native JavaScript later on anyway (looking at you, TypeScript). IMHO there’s no advantage regarding the final compilation and you have to learn a new type of language in addition to creating tool overhead.

That doesn’t mean that I don’t see a need for type safety. It’s just that I’d like to keep using native JavaScript. That’s why I came up with Avocado.

Avocado

Avocado is a small library and pattern guide to help you with type safety and data validation in native JavaScript. It is very very early in development, a prototypish state, a proof of concept. I post this so I’ll be able to find out if other developers share my mindset (see preface) and if it’s worth following this approach. I’ll accept if you tell me this is totally nuts too of course.
Avocado internally uses unified getters/setters and object factories to create a simple interface (interface not in the sense of OOP). Looking back how I came here, in my experience the underlying code might be a little hard to wrap your head around. But once you got it, this kind of programming leads to a more declarative style in an almost natural manner. Which I prefer.

Avocado gives you some tools to work with types, for example:

> av.int(10)();
< 10

> av.int(.1)();
< Uncaught d is not an integer

> av.int('a')();
< Uncaught d is not a number

Avocado allows you to create your own types.

var adultAge = function (i){
  return av(i, function (d){
    if (av.int(d)() >= 18) return d;
    else throw "not old enough!";
  })
};

> adultAge(17)();
< Uncaught not old enough!

> adultAge(18)();
< 18

The real fun starts as soon as we combine this with objects;

var Person = function (i){
  return av.map(i, {
    fullName: av.string,
    age: av.int
  });
};

Using this approach we can define requirements for objects and have them checked upon creation.

var gandalf = Person({
  fullName: "Gandalf the Grey",
  age: 2019
});

We get back an object with setters/getters for each property.

> gandalf.fullName();
< Gandalf the Grey

Each property uses its corresponding type validator.

> gandalf.fullName('Gandalf the White');
> gandalf.fullName();
< Gandalf the White

> gandalf();
< {name: "Gandalf the White", age: 2019}

How do you like that? Have a look at the github repository, to try it out yourself: https://github.com/walterra/avocado

In my next post I’ll talk about on how to move on with this approach in regards to inheritance and nested objects (think Hobbits, Wizards, Orcs!).

Again, a reminder: This emerged as an experiment, a proof of concept, it’s far from really ready. So don’t be too harsh on the code and me :). I know it’s also a bit vague whether this is about type safety, static types or just type validation, I’d still love to hear your thoughts and where this could lead!

PS: If you like this, give it an upvote on Hacker News

15 Kommentare zu An opinionated approach to have type safety in native JavaScript.

15-cw12 — Dock me Amadeus

19. März 2015

Some much for regular blogging rebooted. Anyway, here’s a roundup of past findings.

Docker significantly changed the way I work. But it’s still a love-hate-relationship. I like how you define containers in a self-documenting, reproducable way. ATM it’s perfect for development. However, in production I still feel blind shooting and having nightmares in terms of security. I’m always afraid a wrong issued command might bust the host firewall through its fiddling with iptables (because it did more than once with different firewalls in the past). And while all major cloud providers are jumping on the docker ship, the software itself states that it’s still meant for development environments only. docker-compose (formerly known as fig) boldly states within its help screen: „Fast, isolated development environments using Docker.“. Maybe they should reconsider their versioning being above 1.0 already.

On the coding side, I’m still trying to make friends with the Java world. Slowly I’m feeling more welcome here (mainly thanks to http://blog.paralleluniverse.co/2014/05/01/modern-java/).

By the way, I like how Disqus is evolving. You might wanna follow me over there:
Blog: https://disqus.com/home/forum/walterra/
Me: https://disqus.com/by/walterra/

Keine Kommentare zu 15-cw12 — Dock me Amadeus

video game soundtrack brain hack

5. Mai 2014

I’m not a regular gamer, but once in a while I stumble upon a video game I start playing and it can get quite addictive.

But what I do later on: I grab my pair of AKGs and listen to the soundtrack of a game I was really addicted to while coding. It turns the coding and problem solving into the same kind of addictive game. Can’t stop then.

At the moment I came back to World of Warcraft’s soundtrack. It’s been released unbelievable 10 years back!

Keine Kommentare zu video game soundtrack brain hack

cw3 curated web development links & thoughts

20. Januar 2014

Since I auto-post my bookmarks into a private pinboard account, I thought I’d restart this blogging endeavour with some curated links’n’thoughts.

http://vertx.io/

I’d say vertx.io is my finding of the week. Can’t wait to try it out, it sounds too good to be true:

Vert.x is a lightweight, high performance application platform for the JVM that’s designed for modern mobile, web, and enterprise applications. […] Write your application components in Java, JavaScript, CoffeeScript, Ruby, Python or Groovy or mix and match several programming languages in a single app.

Web Components et al

There’s so much fuzz in JavaScript land all the time. Here’s what I think (at the moment):

  • Keep it simple.
  • Angular is interesting and promising. But I try to avoid behemoth frameworks. While it’s great what it can do, it feels overdesigned and complex, sorry.
  • I nearly fell in love with ReactJS. It’s awesome and fast. But I can’t help it, their JSX approach feels so much like the 90ies PHP spaghetteria that we all tried to avoid.
  • I have no hands-on experience with Polymer. While it smells a little behemoth, it might be the way to go (Standards, baby!)
  • So I try to avoid the large frameworks. Instead I focus on code/dependency management and modular, lean programming patterns. Here are my personal preferences (at the moment)
    • Git for code versioning (+ GitLab)
    • Bower for dependency management
    • RequireJS to modularize your code
    • As a pattern for coding modules I mostly stick to Mike Bostock’s Towards Reusable Charts. He developed it originally as a pattern to do charts/infovis, but I pretty much use it for everything. I think that pattern is a perfect fit for RequireJS.

That’s it.

Keine Kommentare zu cw3 curated web development links & thoughts



About me.
I work at Elastic as a JavaScript Engineer within the Machine Learning team. My current focus is on developing visualization interfaces for anomaly detection in time series data.

Get in touch:
twitter.com/walterra
facebook.com/walterra
walter@rafelsberger.at