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.


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.


Greenruby 183

The reign of the virtual

Yesterday morning, the hunt for Pokemons opened here in Taiwan. I have been watching the crazy adoption of this new trend in the past few weeks. And knowing the asian culture, I suspect Japan and Taiwan are going to make the craziness in the rest of the world just like mild interest.

There are few occasions to notice a huge shift in civilization as clearly as this one. For sure we have noticed that our fellow human neighbors spend more and more time the nose on their mobile devices. But this pokemon enthusiasm bring it to a whole new level. It proves the virtual now begins to overrule the real in term of social conventions. Well, not for everybody, not everywhere, but in a proportion that is relevant enough to be noticeable.

The real world always have been ruling the social activities. Laws and conventions were deciding who is in and who is out, what to do and how to do it right. This is going to change. My main concern is that the future of the social activity is in the hands of private companies. Those companies, legitimately driven by profit, consider the user as a resource, that requires gathering and retention strategies. Like herds. The whole privacy fight is not going to stand too long as cattle (oops I meant user) data is the 21st century gold, and economy (and crazy need for constant growth) depends on it.

And I’m not really happy from this deduction. We are getting captured with advanced weapons generated by behavioral economics and other clever social sciences. They are manipulation tools. Just tools. Sure you can do good with them, but such powerful tools of mass manipulation are not going to stay neutral in the hands of those who want to squeeze our essence (feels like a matrix metaphor, yeah I’m aware of it).

Our mobile devices become interfaces now. Direct access to our behaviors. They already have been great tracking and data collection devices for years. Now they begin to be manipulative with much more effectiveness. Sure, the pokemon hunting doesn’t seem to harm much, but I see it as only a beginning, a trigger. It just makes sense. Everybody can see the success it has. Certainly there are already hundreds of projects that are seeing the light right now at this instant just under the visibility of that opportunity. And many of those will be clever, engaging, and impacting on the real world, by the way of mobile devices, the reverse-remote-control for getting a grip on every human being.

Because I’m an old guy, I’m of course very worried about this future. I have memories of a past where it was so much different. But the young generations, seeing this as the norm, will just fall for it, without question. Don’t get me wrong, I love good tools that can make our lives easier. But they are tools. The intent of their usage matters. Augmented reality just seems to be going to be used with very nefarious intents.

hrum. Well yeah, this is a rant, that’s nothing more. Not an essay, not a study. Just my guts getting spread over the table. Take it easy :)


Greenruby 182

Chatops and machine learning

Since I slowly becomes the chatops specialist where I work, I get to think I want more. Since the beginning we have been interacting with programs essentially with graphical interfaces. First asynchronous if we think about the web, now more and more synchronous, but they are interfaces that are not human. They are designed for giving control to the operators of those interfaces.

But the more we advance in autonomy of our programs, the more we should trust them to sort the information by priorities. The interfaces like Siri, Echo, are much more ‘human’ and conversational. It doesn’t take a genius to speculate that interfaces are going to die one day, except for very specialized usages, and more interaction will be just more conversational.

In the course of my development of interactive agents for technical needs, I noticed that adding just a little bit of intelligence and memory in those agents goes a long way in usability. Especially in chatops, a lot of the actions required from those agents are predicable and repetitive. The development of new features should follow the recognition of those patterns and shorten the path to accomplish some actions. That’s pretty much my job.

But coding this continually is not very cost effective. Tools also change, then patterns evolve. Now all I can think about is a way to design an irc bot that learns by itself. Some program that does real meta-programming and considers its commands as data rather than hard-coded pre-conceived path for the information to flow.

If you know some tools that already do that, can you fire me a mail?


Greenruby 181

Innovation and Consensus

Last week I got to check out 2 javascript frontend frameworks, Choo (the cute framwework) and Cycle.js (the streams power). It feels that nowadays React is eating the frontend world, but there is actually a lot of non-marginal alternatives. It made me think that there is something tricky with the process of innovation. It is born from disagreement. It feeds with discontent.

Those frameworks are born from the refusal to consider React as a consensus, hence it generates an alternative path, exploring different paradigms. In my opinion, and from an global point of view, it’s a sign of vivacity of an ecosystem. Diversity of species guarantees a larger span of choice for the natural selection and a faster evolution.

But consensus and normative approaches have so many virtues. Damn, this is tricky. Well, here is the catch. Unicity in the software ecosystem creates stability, which in turn creates comfort for the actors involved in the industry. Habits get stronger, mobility is easier, interoperability leads to bigger systems with long life-cycles. This is good.

On another hand diversity creates instability, challenges the developers and makes it harder to find common grounds. It favors exploration and smaller systems with shorter life-cycles. In a diverse ecosystem, paradigms and new ideas are born and die quickly. And I think it’s a much more rich ecosystem.

For some reason this duality reminds me of the cathedral and the bazaar. It’s totally unrelated, actually, but maybe there is some kind of interesting parallel in this metaphor collision. But beyond that, there is a real antagonism for developers, and an opposing interest between the development workforce and the software as a living species.

And I have the feeling that on the long run, diversity and innovation win. So you better get used to the discomfort it brings. Train yourself to jump from one framework to another. Don’t let yourself getting lazy by going to the comfortable consensus systematically. This ability to cope with change is your best hope for staying current. Because the change if the way of the evolution.


Greenruby 180

nothing to report

Yeah there are weeks like that, I don’t have inspiration. Or I’m lazy. Or I’m too busy writing javascript tests with mocha, chai and or sinon. Already having 3 times more lines of code in tests that in code and even if coverage says 80% I know for a fact that there are many more cases I need to test. Anyways, there is too much fun for me to just go beyond the traditional gathering of the links for this week. Can’t write a rant. No way.


Greenruby 179

The (in)culture of encryption

A couple weeks ago I had found out that a friend was keeping his passwords in a google sheets document. I was horrified. But he’s a normal person. I mean, not more technical than the next guy, or just a little. He’s using the web interface of gmail for his mail, like many people do (I even know very technical people doing it, which is still boggling me). I looked around and found mailvelope. So I hook him up on it and now he can use GPG.

In the past 20 years I have seen the timid evolution of personal encryption. Oh there are initiatives like Keybase, various simple tools like passowrdstore or Felony that I discovered this week. But it seems that encryption don’t really stick to the usages, unless you have a specific thought about it. Fortunately there is some wise generalization of SSL for inter-server communication, with initiatives like lets encrypt. But inter-personal communication is still wide open.

More and more it is well-known that our data is food for various corporation, governmental agencies, and dark organizations. What will it take for getting the users to claim better privacy? Will it ever happen?

I mean, yes for sure people can use the tools. But it’s cumbersome. Until encryption is embedded in our tools and services, it simply won’t spread significantly enough. There are some projects like Caliopen that try to do so. On another hand, we have seen some services like Telegram which provide such service, and even some mainstream providers like Whatsapp jump into the full-encryption train. So maybe there is hope? I still wonder what’s the part played by Facebook (which now owns Whatsapp) in that move.

The recent fight between Apple and US government was supposed to set some kind of precedent. Too bad it was aborted. But they would have complied at the end, this is my bet. Now that encryption is the only way for companies to legally keep their users safe from legal (and illegal) inquiries, maybe more will consider it?

If you have two onces of technical savyness, please stop running naked on the streets. Gear up and use encryption whenever possible.


Greenruby 178

Open code, a chance for improvement

Since I’m writing code I try to publish as much as I can as open source components. But I had occasion to work in situations where it was not possible. And I noticed some serious differences in the result.

When you publish some code on, say, Github, you can just throw it as is and be done with it. Then you merely use github as a repository provider and don’t care much about anything else. But when you begin to spend some time doing it, you notice that external contributor can bring great fixes, help detect bugs, and generally speaking make your code more valuable in itself.

But this is a two-ways road. To invite people to collaborate you need to address a certain amount of little details. Writing a decently clear README is a demonstration of politeness for any passing guest. It’s just more inviting. Making sure you have a complete enough test suite guarantees you can be sure external contributions won’t mess up existing code (if writing tests in itself was not motivating enough). Refactoring your code by following codeclimate advises will break huge methods in small pieces, making things easier to be improved. Enforcing some kind of style guide will avoid people to get confused by a non-standard code-art. (that person could be you in one year).

All those aspects, when you work at a company as the only coder on one piece of code, you don’t have that much incentive to enforce them. And I know about it because I have seen a huge lot of legacy code that was written that way. With lame tests that only purpose was to enforce code coverage without really testing much, weird code style, epic methods, no instructions. If it’s just you and a couple of friends that you see every day, it’s fine, you can deal with it. For a time.

The fact is that exposing your code brings an incentive to work on the (apparently) non-essential aspects of your code. But those aspects really bring a huge improvement on the long term. Which leads me to consider that opening source code is a way that can lead to make it better.

An usually, I noticed that the bosses don’t care if it’s open or not, as far as there is no trade secrets revealed. But well we write so much code that if business-neutral for many things. At the end of the day, it’s only the matter of asking the boss if you can free this or that code, and then it’s on its way. Even more if the code is published under an organization on github, there is even more incentive to make it clean, and it will also help possible candidates to understand what kind of stack you are dealing with, and what kind of principle you try to enforce. Even if it’s actually only enforced in your open source code and the hidden code is messy. Haha.

So, I ask you now, what in your current codebase could you extract as an open source gem? or node package?


Greenruby 177

Remote working

For some random strange reason I had a lot of links this week about remote working websites. I know it’s a very real topic for our craft. But I still see a lot of companies that have hard time coping with the concept.

On one hand, there is a shortage of technically skilled staff. The growth of the tech industry and especially the online services is way too fast for the education system to catch up. It’s been like that for pretty much 20 years now. And there is an unbalanced repartition between where the growing companies are and where the growing population of techies are. So it would only make sense that either relocation would be much easier or remote working much more widespread, no? Well, no. Relocation is bound to laws that are not driven by the only technical area. And remoting is dependent on a cultural and also legal shift.

Because working with remote staff, many of us know what it means. First it involves a level of trust in the staff that is unprecedented. The same level of trust you need to invest when working with a contractor, actually. Then the old-fashioned control and command system in place with traditional management systems gets totally inefficient.

More even, to be efficient with a remote team means adopting a work organization and tools that are specifically thought for this setup. From what I can experience, it’s either one or the other. When half the staff works in an office locally it’s not easy (yet not impossible) to be efficient with another half remote.

Some stuff will be likely to happen locally with old ways of oral communication and meetings with sparse note-taking. That will put the remote staff in the dark of some parts of the internal process. It may create a double-speed kind of organization, there is the ones that are full speed and the ones that are just, well, not in the core. Oh it’s still possible to make it work. It’s just harder.

Or maybe it’s like the web and the mobile. Slowly companies need to become remote-first and then eventually also work on local office-based scale. But there are still various barriers for having a real remote-friendly world anyways. The legal status is not clear,m for example, money transfers between countries, compliances with social coverage conventions, no international law seems to cover international employment with individuals.

From what I can understand, remote working from a distant country is still a hack, legally speaking. Companies need to find tricks. Luckily, hacking is something we are not bad at. But still. I wonder when it’s going to change, and see a legal ground for a really normal remote working context.


Greenruby 176

The virtues of duplication

Few weeks ago I began to prepare a copy of the Green Ruby Template system for the usage of the Remote Meetup team. It’s kind of ironic because, from some point of view, this code is a sin and was not written in the perspective to be generic. It’s deliberately not constrained to code best practices, it’s joyfully messy and blatantly suboptimal. It was a quick and dirty scripting solution, it could have been a set of shell scripts, well it happens to be using ruby. Check it out if you don’t believe me.

But it’s doing the job for years now. It’s a builder code, so it’s run as a convenience only a few times a week, it doesn’t really need to be fast. It just needs to do the job. Trust me I like good code, with clean design and full test coverage. But this one was just an intimate assistant of mine which was not really a software. Just some automation scripts.

And now here it is, I get to face a situation where some friends need the same setup and I can’t just give them the code, it’s so custom. But there have been only a few changes to make and it was ready. But the interesting part is in the process. While duplicating the code for the Remote Meetup newsletter, well, I extracted some stuff, made a config file to remove various hardcoded things.

Well it is still a big ball of dirty code, but in the duplication, it got more generic. I love that feeling which brings the software development world closer from the biological world. There is some kind of evolutionary process going on in the life of a software. It takes many forms and I like it when I get reminded of those similarities. I could go on and on about the topics that an open source ecosystem is necessary for the diversity of code to flourish and make evolution possible in a totally Darwinian way.

So this simple operation was just illustrating one principle: when you share your code you shape it and make it more generic in the process. It can have various beneficial side effects beyond the single act of duplication and adaptation. I find it’s also true when you publish your code as an open source project. If it gets some traction and people start to use it, they will import their context in your initial ecosystem and bring the same kind of adjustments. Making it stronger, in some way.

Anyways, the Remote Meetup News website and newsletter generator is now ready, and you may find that the design is kind of familiar. Well, the rule of the path of least resistance also apply here for sure. I begin to apply back on Green Ruby the changes I made over there. I suspect the third duplication, of any, will be the extraction of the common parts in a separate codebase, like a gem with a lib.