E1 Service.

Sharing the work.

My e1-service library is now on NPM.

Well, it’s actually been there the best part of this month but I’ve been tinkering with up till last week. I’m pretty happy with 0.2.2 which is the current version – but not ready to publish the first major version.

So what does it do?

As I mentioned in my last posts, programming is all about pattern-matching. And like every repetitive task, writing the same code over and over again gets boring – not to mention counter productive. So we try to bundle repetitive code into a library, and if we are happy with it – share it (ideally you want to make money out of it – but life is too short).
So my e1-service library, or package as they like to call it on npm, is a bundle of AIS service calls.
The objective is to make the AIS service calls, such as authentication and form request, consistent and traceable. Basically have a single answer for:

How you make a form request?

Nothing less and nothing more.

What’s next?

I’m glad I asked myself this question because I’m working on hello-e1. A how-to write mobile app with e1-service. My principle is:

Nothing beats doing when it comes to learning

The idea is that with hello-e1 you can short-cut the learning curve to Angular, Ionic and AIS and focus on how to use E1 on a mobile app.

No special ambition here, but my second principle is:

Failure is the best teacher of all

So it should all make sense.

And since I’m on the philosophical run, I like pass one from Brian of Mooney’s

If you give it 100%, then you can’t fail

At first I thought this is some kind of Irish optimism that you somehow keep up with loads of Guinness. But there is a punch line:

If it still fails, then it wasn’t meant to be

Now, how’s that for philosophy!