2016-11-13

Greenruby 197

My lovely Chatbots, sick already?

Recently I have been to a meetup about chatbots. I was expecting something technical. But it seems that I was totally mislead on what chatbots are. They are visibly now more of a marketing tool than just a cool piece of technology.

I’m pretty convinced that web interfaces are going to die slowly in favor of more conversational interfaces. But in past technology shift we had some time between appearance and marketability. Like with the web, the social networks, etc. No more. Chatbots are immediate slaves for sales volumes. All the blooming of new services for ‘building your own bot’ are just totally geared towards customers management and acquisition.

My naive assumption was that assistive conversational interface could have a larger scope. But well, the market is driven by what sells, and what sells is what make more sales. I just hope it will have a nice border effect to improve chatbots as a tool or as a general interface to access information.

But my instinct warns me against the potential invasion of our social world online by all sort of aggressive automated peddlers. The same way we get robotic phone calls. Chatbots are going to be the new color of spam?

2016-10-16

Greenruby 193

Is Facebook the new NPM?

This week there is a lot of noise in the JS ecosystem, on various trends. But the most noticeable is about Yarn. Yet another package manager for js, that states it opens a war against NPM (in soft terms but clearly enough). The long post from Facebook about it demonstrates a clear effort to push things forward about NPM shortcomings. The reaction on hacker news is pretty verbose.

It provoked a public response from NPM to try to explain that, nop, it’s not a war. But I keep feeling that Facebook is slowly taking over another piece of the javascript world. For now, it doesn’t seem harmful at all, but my instinct lights a various number of warning bonfires.

But for real, it was more than time that the supremacy of NPM was questioned. It has a lot of flaws and the number of posts about this event proves that the community was kind of waiting for something like this to happen. Like this cheatsheet, various articles like this one, this enthusiastic post from Yehuda Kats. But not everybody is happy about how things are done.

Personally, I like the technical direction it takes. But I hope that like io.js went back to node.js, it will eventually merge back to NPM, really. But I have the feeling it is not going to happen.

2016-10-09

Greenruby 192

The JS toolback hell

This week I laughed a lot while reading How it feels to learn JavaScript in 2016. That article had a pretty good response, like it hits a nerve.

But seriously it’s clear that we are at a transition time in Javascript evolution, and there is a huge chaos of possible alternatives to everything. It feels like an ecosystem where the natural selection didn’t operate its magic yet. It’s like there are things in suspension that are going to fall in order at some point eventually.

My personal bet is that things like elm will win the race, because with its embrace of functional programming it seems like it opens the door to interpretation with yet-to-be-written faster and more direct compilers (rather than transpiling to js). But that’s just a hunch.

In the while, front-end craft is now a wizard arcane art. It can’t be acquired by pure reasoning and logic, or reading a doc. You need the map of the landscape for knowing the possible choices and alternative intermediary solutions. For part-time front-end people, it’s just hell. For now.

2016-10-02

Greenruby 191

I’m in holidays

Great occasion to kick thunderbird byebye and spend some time on configuring my mutt to make it real again, after 6 years of click-click for mail. I was a mutt user for a very long time, and my pause for trying a GUI mail client just had to have an end. But the mail has clearly become something else now. Actually much more volume, but much more automated things, and news feeds. Or it’s just me?

2016-09-25

Greenruby 190

A stress-free life

Next friday, I’ve been told that I have to stop working for 2 weeks. Well, for people that have a normal life and/or kids, it’s a pretty good news. For people that get heavy pressure from their work, it can give some air. But I wondered why I didn’t feel like I ever felt the need for holidays. I take them by principle, but I’m usually not really eager to get them.

After some consideration, it all sums up to some kind of discipline. I refuse stress on a daily basis. I want each day at work to be enjoyable and debt-free. It’s a bad news for some category of employers. The same way those consider it’s acceptable to accumulate technical debt, they apply the same principle on human-life debt. Put people under pressure, get a loan on their health, that will never be repaid. So, I just refuse pressure, the same way I would refuse to eat meat if I was really vegetarian (which I am only part-time).

Really I have more trouble with holidays because they bring a gap in the continuity of work. You get back and there is a lot to catch up on. I would prefer to have just one hour work less per day than week-long breaks. But that’s just me. It would be totally different if I wanted to travel for fun or if I had kids. My case is not reproducible.

But the baseline remains valid. whether you have plans or not for holidays, they should not be required for having a balanced life. Stress has to be fought on a daily basis and not by using breaks. Breaks, in such case, are even more enjoyable, if you have the context for it.

The best way I know to push stress away is to put my efforts into what I do, in a way that I’m self-aware that I’m really doing what I can to fulfill my duties. If someone is not happy about the output, that’s their problem not mine. If it leads to some awkward context, then it’s broken and I will reach out to find a better work context. I apply that principle for more than 20 years now and I can’t remember last time I felt stressed.

2016-09-18

Greenruby 189

The art of learning

In my review this week I read that Old Geek post, which has a lot of comments under its feet. This is quite interesting. But I feel there is a confusion here.

From my experience, age is often related to stagnation. The more you accumulate, the heavier you are. It’s heart-breaking to abandon years of investment in one type of knowledge. Therefore, generally speaking, older people are less flexible and less likely to surf on the waves of the new technologies.

But I can tell you as a fact that this is just a natural human law, that, like many others, can be bended. Bended by discipline, the same way we overcome our animal instincts. There are many old practitioners of our skill that became master in the art of change. The sacred art of eternal learning. The wisdom of daily questioning of previously acquired knowledge.

Obsolescence is not a question of age, but just a question of personality, environment and priorities. I know a handful of such oldgeeks that didn’t yet reach their 30’s. And personally (in my 49), I won’t stop surfing any time soon. hahaha.

2016-09-11

Greenruby 188

Observability and Digestibility

This is a word I love. I found it again in a recent blog post about system blindness and it reminded me how critical this need is. Our systems get more and more numerous and small. The reliability and debugging of a platform now goes into various loops given the multiplication of actors.

Observability should be one core pre-requisite when designing a service oriented architecture with micro-services. But just having everything plugged to some ELK is not going to help that much. I feel that there is a new job in there. Some function that has to be fulfilled. Something to reduce that vast amount of data into something that makes sense. An intermediary that will correlate logs from various sources. It would put them together and reduce them to some meaningful ‘events’.

So I think observability is not enough. Digestibility is what makes observability worth it. Maybe such tools already exist? Hmm, probably in the containers worlds there is something like that. Is there not?

2016-09-04

Greenruby 187

Get out

If you only ever have lived in only one country, you really should consider fixing it. Going live in another country for some years or more is just such a way towards a richer life. It’s usually easy to recognize people that are multi-rooted, as they often have an increased depth in their personal philosophy.

We are lucky, in our craft, to have various opportunities to travel and work remotely, or for foreign companies. Many of you are already aware of those benefits. But to the others I can just say this: use this opportunity! Get out!

2016-08-28

Greenruby 186

To be remote or not to be remote …

Earlier this week I read an article on linkedin, deliberately anti-remote, and a bit later on another one very pro-remote on freecodecamp. I’m tempted to think one is the response to the other. But maybe not.

The fact is that switching to a remote organization is a tricky move. It feels like the move from monolith to micro-services, honestly. People that make decisions about it rarely envision the extent of the change. And those change look similar in nature. Team architecture and software design are not that foreign. More autonomy for services or people, self-contained activity, requirement for clear communication channels and protocols, extensive architecture for monitoring, reporting or just plain visibility, more debugging tools and processes, and much more.

The same way one will have to think about all those when switching to microservices, the one that thinks about making his team remote will also have to consider the exact same parameters. But that is all on the principles. About the implementation, remote teams really need a strong chat culture, an easy and transparent logging policy for all communication channels, various tooling similar to chatops tools for assisting communication activity. Remote organization also need to have all their processes online, and not need much (if at all) any synchronous meetings.

From my perspective there are various very beneficial side-effects to make a team remote. There is more traceability as everything is online and not in corridors anymore. In some cases that I experienced, it also leads to a less arbitrary perception on team members, because they can be judged more on results (if you have measure tools prepared accordingly) than on attitude and mouth-skills (did you noticed that irl meetings are sometimes just a mouth-o-cracy?). But it’s accurate to say that on a short term, it is more time consuming. The real benefit rises on the long run.

What I didn’t find in any articles on the matter, is the life-cycle dimension. A software project has a life expectancy, from a business point of view. It’s the same game as with the technical debt. It is acceptable business-wise to live at credit for a time, until a certain milestone. A lot of projects are just extended MVPs intended to convince big money that they could deserve some attention. For such project, you want very fast paced environment. It’s easier to coerce your slaves employees to go above and beyond the expectations, when in a physical environment. This is a disposable context, and you can skip team debt as much as technical debt. And you really need physicality for that purpose.

So, I would say, if a company is not making the move towards remote organization, maybe there are very good reasons for that. But I will be very cautious to understand what are the real reasons. They may stink. And if they are remote, but they just came to it recently, I would be careful about the tooling they prepared for it.

2016-08-21

Greenruby 185

Working out

During the past year I have been doing some working out. No no there is no fitbit involved. Are you crazy? My physical activity includes a strict refusal of pointless efforts. I deliberately choose to use the bike rather than the bus, it has the purpose of transportation,. But just getting sweaty for the sake of it, well, that’s not my thing. I’m talking about a git-commit working out. I decided to have one commit a day on github (minimum) and instead of the fitbit or whatever phone app, I used the github timeline as a monitor.

So that’s one year now and I got my github timeline all green. In itself it doesn’t achieve anything except for myself. I mean, it’s quite easy to fill up a timeline with fake entries. But by getting this challenge of one commit a day, it led to some valuable outcomes. I got some more work projects validated to be published as open source. Whenever I was not feeling inspired for code commit, I was chasing typoes in my Readme’s, or dependencies upgrades in my gems.

Overall, it had quite a good impact on my coding publication, on the updating of my blog (well, that blpg mostly gather the rants I do here), and various other small details. Well, I’m not a very famous open source coder, just an average joe. But a persistent one. It’s very easy to just upload shit on github and forget about it. Having this regular commitment made me come back on some old things, keep them current somehow.

Getting some routine in place that includes open source activity has various benefits, even when you don’t have an audience. You should try it.