Sunday, October 22, 2017

headless-chrome - getting started in ruby

headless-chrome

- Install Chrome 59 or later from google.com/chrome

- download chromedriver and put in a new folder called 'chromedriver'; so the path to the binary is similar to - /home/sai/chromedriver/chromedriver

- now we have to add the above binary's path to PATH 
-- Open the below file in nano editor
nano ~/.bash_profile
-- add the below line
PATH=$PATH:/home/sai/chromedriver export PATH

- gem install selenium-webdriver

- gem install chromedriver-helper

- Now we can start executing the scripts found in -  https://readysteadycode.com/howto-scrape-websites-with-ruby-and-headless-chrome

Wednesday, September 27, 2017

Git related: DeepGit - tool to investigate the history of source code

https://www.syntevo.com/deepgit/

DeepGit is a tool to investigate the history of source code. It is based on git blame and makes it easy to trace changes to a line or block of code. DeepGit will detect code movements, even if lines are not identical.

Thursday, September 7, 2017

Rails debugging related

Use sth similar to below alongwith binding.pry

caller.select{|c| c.include? "rails-project-folder-name"}

This will give the list of callers (methods) that are your code.


Wednesday, August 30, 2017

Try Ruby in the browser

The software engineering rule of 3

https://erikbern.com/amp/2017/08/29/the-software-engineering-rule-of-3.html

Excerpts:
 first rule of 3. Don’t worry so much about code duplication if you only have two classes or two functions or whatever. When you see a pattern in three different places, it’s worth thinking about how to factor it out.
...
...
 second rule of 3 — you’re not going to get the system design right until the third time you build it. 

Sunday, August 27, 2017

Kibana related: Searching in Kibana

https://lucene.apache.org/core/2_9_4/queryparsersyntax.html

Search for 2 strings using AND operator:
"15-0001" AND "10-0005"

Choosing a frontend JS framework

https://medium.com/front-end-hacking/how-it-feels-to-learn-javascript-in-2017-a934b801fbe

Excerpt:
Interesting. Which one should I use? The big ones are React, Angular and Ember, right?
-They’re all good. If you want to write your front-end logic in Handlebars use Ember. If you want to write your front-end logic with HTML attributes use Angular or Vue. If you want to write your front-end logic with JavaScript use React, Mithril or Inferno.

Tuesday, July 25, 2017

redbus move to .Net Core & their blog

imba.io

Imba is a new programming language for the web that compiles to highly performant and readable JavaScript. It has language level support for defining, extending, subclassing, instantiating and rendering dom nodes. For a simple application like TodoMVC, it is more than 10 times faster than React with less code, and a much smaller library.


Saturday, July 22, 2017

Blockchain related: A hacker stole $31M of Ether—how it happened and what it means for Ethereum

Advice from Claude Shannon

10,000 Hours With Claude Shannon: How A Genius Thinks, Works, and Lives:
https://medium.com/the-mission/10-000-hours-with-claude-shannon-12-lessons-on-life-and-learning-from-a-genius-e8b9297bee8f

Excerpts from the above article:

1) Cull your inputs.
2) Big picture first. Details later.
3) Don’t just find a mentor. Allow yourself to be mentored.
4) You don’t have to ship everything you make.
Vannevar Bush left his imprint on Shannon in another way: he defended the value of generalizing over specializing. As he told a group of MIT professors:
“In these days, when there is a tendency to specialize so closely, it is well for us to be reminded that the possibilities of being at once broad and deep did not pass with Leonardo da Vinci or even Benjamin Franklin. Men of our profession — we teachers — are bound to be impressed with the tendency of youths of strikingly capable minds to become interested in one small corner of science and uninterested in the rest of the world. . . . It is unfortunate when a brilliant and creative mind insists upon living in a modern monastic cell.”
Bush encouraged Shannon to avoid cells of all kinds
5) Chaos is okay.
6) Time is the soil in which great ideas grow.
7) Consider the the content of your friendships.
8) Put money in its place.
9) Fancy is easy. Simple is hard.
“Almost every problem that you come across is befuddled with all kinds of extraneous data of one sort or another,” Shannon said, “and if you can bring this problem down into the main issues, you can see more clearly what you’re trying to do.”
10) The less marketing you need, the better your idea or product probably is.
11) Value freedom over status.
12) Don’t look for inspiration. Look for irritation.
Shannon’s most evocative formulation of that elusive quality put it like this: it was “a slight irritation when things don’t look quite right,” or a “constructive dissatisfaction.” In the end, Shannon’s account of genius was a refreshingly unsentimental one: A genius is simply someone who is usefully irritated. 
 

Wednesday, July 19, 2017

http client - Requester


Steps for developing a React app from scratch

Excerpt from the book FullStack React (Chapter 2 - Components)

In fact, this follows from a handy framework for developing a React app from scratch:
1. Break the app into components
2. Build a static version of the app  
3. Determine what should be stateful
4. Determine in which component each piece of state should live
5. Hard-code initial states
6. Add inverse data flow
7. Add server communication

Chrome Dev Tools related

Sunday, July 9, 2017

Jonathan Blow talk - shares some hard-earned wisdom about programming & projects



His talk is about 38 minutes long.

Alexander Pope: A little learning is a dangerous thing

From http://norvig.com/21-days.html
Above link is already part of a previous blogpost, but the below quote is worth a new blogpost by itself.
As Alexander Pope said, a little learning is a dangerous thing.

Peter Norving: Teach Yourself Programming in Ten Years

Peter Norvig is a director of research at Google Inc.

He wrote way back in 2001 - Teach Yourself Programming in Ten Years -
http://norvig.com/21-days.html

Peter Norvig: Being good at programming competitions correlates negatively with being good on the job

Peter Norvig is a director of research at Google Inc.

http://www.catonmat.net/blog/programming-competitions-work-performance/
"Being good at programming competitions correlates negatively with being good on the job"


Broad generalizations will not stand up in a court of law, but they do point towards things to ponder.

My takeaway from the above video - Trying to get things done quickly, all the time, can be a Negative thing.

Thursday, June 29, 2017

Java EE -- The Competitive Advantage For Startups


From Adam Bien's blog:
"At the infoshare.pl 2017 conference in Gdansk I got 30 minutes time to explain why Java EE is happily used by startups with live hacking. Deployment to Amazon Cloud (AWS) included:"
Java EE -- The Competitive Advantage For Startups
http://adambien.blog/roller/abien/entry/java_ee_the_competitive_advantage

Friday, June 16, 2017

Instagram Makes a Smooth Move to Python 3

https://thenewstack.io/instagram-makes-smooth-move-python-3
By all reports, things went really smoothly — how did the team make it happen so seamlessly?
Guo: An important factor was, if you look at how we were migrating, we would constantly check in small changes into the master branch, so we were never merging major diffs. Getting the most bugs fixed, with a smaller audience iterating in small steps: that was the key approach to maintaining stability while still moving quickly.

Wednesday, June 14, 2017

Hard work

A reminder of how hard one should be working.. in any field..

https://www.reddit.com/r/movies/comments/67qzrx/hello_reddit_i_am_actor_and_artist_val_kilmer_i/
CatchMeKillMe 243 points244 points  (23 children)
Val, any advice for someone attempting to break into the business?
[–]OfficialValKilmerVal Kilmer[S] 1413 points1414 points  (22 children)
work till you cry yourself to sleep every night for months on end. work so hard you pass out and wake up crying. become a world class athlete. Read Shakespeare every day to learn about human nature. EVERY DAY. FOR DECADES. never ever ever ever ever take a day off. And never complain. Its the best job on earth and worth it when you break thru. Dustin Hoffman they say couldn't act his way out of a paper bag, and I knew Kevin Spacey since he was like 15 and he was sooooooooooo bad it used to hurt my eyes. But boy did he work hard and deserves all his awards.

Saturday, June 10, 2017

A Dive into Ruby’s Rack

Thought 4: 2 step Code Review - 1) Solution Review 2) Final Code Review

As a software developer, we are expected to tackle problems of all sizes - minor bug-fixes to developing new features, i.e. we are expected to come up with Solutions and then write Code for them.

It is important to note that this is a 2 step process -
1) come up with a Solution
2) write code

Code Reviews have become an established step in software development, but they cover mostly the 2nd step. Reviewers usually find it very difficult to suggest wholesale changes like suggesting a different solution because of the risk of coming across as a 'bad guy'.

There is no concept of a Review for the 1st step i.e. no Solution Review at present.

It is assumed that a developer will come up with the correct Solution. Herein lies the problem.

First and foremost, most problems, even minor ones, have Multiple Solutions, and the Developer has to choose the best amongst them. Sometimes the Developer working on the problem might not be aware of other Solutions.

Hence I believe that a Solution Review will help with non-trivial bug-fixes/features. The greater the impact of a problem/solution, the more number of senior people that have to review the solution.

Solution Reviews can probably take place in either of the following 2 ways:

1) via Discussions
  • a developer discusses with one or more team-members and/or team-lead, his/her solution to a given problem
  • effort is made to arrive at a consensus amongst max people in the team as possible
  • if Jira or another project-management tool is being used, a simple Comment is added that says that 'ABC has reviewed the solution'.
OR
2) via a 2 step Code Review process
  • these days Code Reviews happen via pull-requests similar to those used when using GitHub 
  • 1st step: "Initial/Solution Review" - When a Pull Request is submitted, it can be labelled as "Initial/Solution Review"
    • Such a label can serve as an indicator that the pull-request is in the 1st stage of Review
    • This sets the expectation to everyone, i.e. the Developer as well as the Reviewers, that the solution that has been implemented, is up for debate
      • traditional code-reviews can be painful when the Developer and the Reviewer have different expectations of the Code Review's outcome, so this setting of expectation, is very important
    • More people are likely to review/discuss when there is less chance of hurting the confidence of the Developer
  • 2nd step: "Final Code Review" - After 'Initial Review' has taken place, the Developer submits a pull-request again that is labelled with "Final Code Review"
  • Note that both the steps of the 2 step process have to be Mandatory - Otherwise, as time goes by, it could morph/devolve into a single-step traditional Code Review process.

Note: Both of the above solutions can be used together too.

Thought 3: Defining characteristic of a team - how they discuss

Note 1: I wrote the below from the perspective of a team of software developers, but a team could also be a couple, or a family, or a group of friends, actually any group that has to make decisions on a regular basis.


In my opinion - A Team is Defined by HOW they Discuss.

I am not saying that, in order to be considered a 'good team', a team has to discuss a lot. How they discuss, whatever they discuss, and how decisions are made is what is important.

In general, today, there is a lot of emphasis on Productivity - a measurement of work done by a team.

In general, there has been a backlash against having too-many-Meetings.

In a continuous quest for Productivity, sometimes teams may sacrifice/forgo Discussions that actually need to happen. This can happen when there is a feeling that Discussions do not qualify as Work.

I have the opposite opinion. Discussions are needed to arrive at Solutions.

Discussions/Brainstorming/Solution-Reviews help in the following ways:
  • prevents the dreaded-feeling-of-exclusion - give everyone the opportunity to propose/debate/just-listen-to solutions Before a decision is made
    • when decisions are made without a discussion, a lot of times, people get angry/discouraged Not by the decision itself that has been taken, but by the fact that they were not considered important enough to be a part of that discussion (even as listeners).
  • prevent Blunders
    • when more than one person is involved in arriving at a Solution, the chances of making Blunders reduces
    • this increases developer's confidence & happiness
  • keeps everyone in the loop i.e. share information with everyone
    • On a daily basis, people work on code that others wrote, so sharing of information is very important
  • lets everyone know that they can influence decision-making, and in fact are expected to do so
  • levels the playing-field
    • gives the chance for talent/knowledge to come out
    • junior devs can debate with senior devs or the lead and get their solution accepted if it is the better one
A related problem is - a team has to decide how Information would flow within it:
- whether it will Pushed to everyone
OR
- if it will have to Pulled by each team-member.

Teams that have discussions involving everyone on a regular basis, would be following the Push strategy and I feel that, that is a better model to keep everyone motivated which is very important to achieve success as a team.

Note 2: Related: There is general consensus about the importance of 'etiquette of discussion' - http://www.exforsys.com/career-center/group-discussions/group-discussion-etiquette.html

Thought 2: Why software developers tend to move frequently between companies

Suppose that there is work to be done always.

Some developers are continuously working to get those things done. There are some developers who get some of those things done, and then spend some time learning - new stuff or old stuff.

There is no clear demarcation about when to do each of them - working & learning. From what I know, most companies, if not all, expect people to learn on their own time. Below I am going to try to explain why this is ultimately not beneficial to a company.

When there is always work to be done, it falls on the judgement of each developer to take the call on when to do work and when to learn.

Like everything, when something is left to the judgment of each individual, you will find that different individuals take vastly different decisions (as to when to work and when to learn).

Sometimes, the decision is taken out of their hands too. This happens when there is a lot of work always, which is mostly the case with software companies.

The logical conclusion to the above line of thinking would be - if left to their own judgement, in an environment where there is always work of some kind or the other to be done, developers will tend to just keep working all the time and will tend to postpone learning, waiting for the time when the workload would become less, which almost never happens.

Can we attribute fault to the people who do the above?

In a corporate world, the answer would be Yes.
In the engineering world, where a team is working for years together on building/maintaining one single product, I feel the answer is more complicated.
Irrespective of who is to blame, in a product-company, it is in the best-interests of the company to not allow the above to happen (as I will describe below).

If developers work in a company in the above fashion, then after a few years, the following will happen:
  • developers get bored with the work i.e. motivation starts to decrease
  • developers start to feel insecure if the skills that they are using daily are not what are in demand anymore (outside the company), and new skills are being sought after in the market
    • the software industry is an extremely fast-changing industry and today's-in-demand-skills go out-of-demand in a few years time
  • there is increased pressure to be successful in the current company due to the above insecurity; and this increased pressure tends to manifest itself in negative ways - people losing their cool with each other over minor things, office-politics, etc.
I think above are the reasons why most developers don't stay at any given company for more than a few years.

When people leave, they take with them a wealth of knowledge - informal training received over word-of-mouth, experience specific to company's problems, history of decisions made to get the product to where it is, etc, and not to mention, cause a loss in morale of the remaining team-members.

So what if people leave? Can't we hire new ones?

In the corporate world, I have heard this statement multiple times - "no one...no one is irreplaceable". That is how it is structured.
However in the engineering world, I feel there are 2 categories:
- A few brilliant Lead engineers form the backbone of the entire company. Such people are considered irreplaceable and that is straight-forward logic.
- the Rest

What about 'the Rest' ? Are they replaceable or not?

In my opinion, the ideal team is a set of brilliant Lead engineers who are supported by an ever-improving team of senior/mid-level/junior engineers. If there is churn within the team of senior/mid-level/junior engineers, the Lead engineers will have to take the time to train the new hires, and you can tell that if it happens a lot, it is not good.

In the above sense, every team-member is important.

So my opinion is - a small product-company, should not have its hiring/retaining policy built similar to a corporate-company. People do leave due to one reason or another, but the core policy should be to try super-hard to retain everyone it hires and trains.

Super-hard? How?

As outlined in a different post (http://psjp-learn.blogspot.in/2017/06/building-machine-that-makes-machine.html), I think, unless a company considers that continuous-training of each developer is an integral part of its philosophy (and somehow incorporates continuous-training in its software-engineering-process), the above negative phenomenon cannot be stopped.  

Note: Above, I have not mentioned the monetary aspect, which I do think, plays a huge role in a person's decision whether to stay or move. But I think as developers tend to become more senior (in experience and age), their salaries tend to stabilize, people start to have a family of their own, and the family's needs get tied to a location and a routine, and hence this factor almost ceases to have any impact many times.

Friday, June 9, 2017

Thought 1: Training Software Teams - Building the machine that makes the machine


Elon Musk at an annual meeting:
The most important point I want to make is [that] the true problem, the true difficulty, and where the greatest potential lies is building the machine that makes the machine. In other words, building the factory … like a product,” said Musk at the annual meeting (starting at 2:20), predicting a new factory would deliver a “ten-fold improvement” in productivity.
As a software developer, I felt that we can discuss, in the same way, about software-teams that are building software-products.

A Software-Team can be thought of as the 'machine that makes the machine', and itself should be treated as a 'product'.

If the software-team is the machine that makes the machine, then how should a company take care of it?

When you talk about a Machine, the aspects of Maintaining it, Making it Better, come into the picture.

What steps can a company take towards a software-team to 'Maintain it & Make it Better' ?
One step a company can take is taking the responsibility of Continuous Training.

How is this different from current thinking?

Current thinking seems to be:
  • Hiring the right people = Building the machine that makes the machine
  • Continuous Training is the responsibility of the Software Engineer and not the company
However, with the new perspective of a software-team itself being a 'product' and being a 'machine that makes the machine', it is very clear to us that hiring good people is only half the job. Maintenance is the other half, and it is in the best interests of a company to take care of Maintenance too.

My personal opinion is that a lot of software developers move between companies at a frequent rate due to situations/problems/environments that arise as side-effects of lack of this Maintenance.

Current processes like Scrum are all about Project Management. But Project Management is just one aspect of Software Engineering. Perhaps something similar to Scrum has to come along to take care of the importance of Continuous Training.


Blockchain explained nicely

A very basic visual introduction to the concepts behind a blockchain.
Introduces the idea of an immutable ledger using an interactive web demo.
If you are interested in playing with this on your own, it is available online at:
https://anders.com/blockchain/

The code that runs this demo is also on GitHub: https://github.com/anders94/blockchain-demo

Sunday, June 4, 2017

Markojs

Elixir related: GenStage and Flow - José Valim (Lambda Days 2017)

GenStage and Flow - José Valim (Lambda Days 2017)  

José will explore the rationale and design decisions behind GenStage and Flow, two abstractions that have been researched and now implemented in the Elixir programming with a focus on back-pressure, concurrency and data processing.

Friday, June 2, 2017

Electron related: Electrino

https://medium.com/dailyjs/put-your-electron-app-on-a-diet-with-electrino-c7ffdf1d6297

Excerpt:
For small apps, there would be another way. Instead of bundling the web runtime with each app, they could use the system-provided web runtime instead. Both macOS and Windows contain a competent modern browser engine (WebKit on Mac, Edge on Windows). This engine is typically already loaded in memory. By using the system-provided runtime, Electron-style apps could become much slimmer both in terms of on-disk footprint and RAM usage.
I’ve just released the first version of a runtime named Electrino which does exactly this.

Ruby related

Sunday, May 21, 2017

Code Reviews related

Want to note down this thought so that I can think about it more later:

Problem:
- code review is usually done on a pull-request
- code-reviewer usually feels some pressure to not suggest trivial changes
- developer who wrote the code also feels pressure to not submit anything for code-review until he/she has reached a certain point
- note that the developer is getting too invested in his/her code by the time his/her code goes to code-review
- since the code-reviewer is aware of this, he/she might feel some pressure to mark the pull-request as 'code reviewed'

Possible Solution:
My thought is:
- developer submits a 1st pull-request that is explicitly marked as Temp Pull Request (and Do Not Merge label)
- this 1st pull-request is only for getting feedback (big and small changes)
- this 1st pull-request will not get merged even though it might be good
- developer has to create a second normal Pull Request which he/she is more confident of
- this second normal Pull Request will also have to code-reviewed and will be a candidate for getting merged

Advantages:
- less pressure on developer when giving the Temp Pull Request for review
- less pressure on code-reviewer while offering feedback for a Temp Pull Request
- Based on whether a reviewer is looking at a Temp Pull Request or a Normal Pull Request, he/she can be in the proper mindset to review the code
- The Normal Pull Request can include a link to the Temp Pull Request. Reviewer can see comments of the Temp Pull Request to get more context.

Nothing Matters More Than Coding Fast


The Future of Advertising: Brave and the Basic Attention Token

Saturday, April 29, 2017

RealWorld TodoMVC - Medium clone using different frontends and backends


https://github.com/gothinkster/realworld/blob/master/README.md

Also have to checkout - http://todobackend.com/

Spoilers: they have you make a blog.
A blog. One of the most simple inventions that never would have existed without the web itself. And it takes full advantage of the web too: querying & persisting data to a database, an authentication system, session management, full CRUD for resources—and now these days social blogging platforms (like the site you’re reading this on) have also perfected relational features like following, liking, and commenting. A blogging site is the perfect example of a simple yet robust web application.

d3.exprrss

'General' Rules/Advice/Reminders to developers like myself

1) Assumptions
Make no assumptions.
Try to confirm in any way possible - e.g read documentation, ask someone, look more closely at the codebase, google, etc. etc.

2) Abstractions
Learn to view any system as consisting of layers of Abstractions.
Thumb-rule: To fix an issue - Work at the highest level of Abstraction as possible.
Knowledge about all levels of Abstraction is desired, but, among all the levels of Abstraction where solutions are possible, fixing a bug should be done at the outermost level of Abstraction.

E.g. Bootstrap widgets use jquery internally. Use the functions that Boostrap provides when working with Bootstrap widgets. When everything that Bootstrap provides proves to be insufficient, then use jquery.

3) Developer Testing
Test end-to-end, the feature that you are touching.
And that is the bare minimum.
In addition to the above, we have to think about all the other areas that could get affected by our changes.

E.g. If you are touching Step 2 in a feature that has 5 steps, we have to test all the 5 steps, and not just Step 2.

4) A good developer is a Power User.
We have to know about the things we are developing for.
We have to constantly be using what the users are using or will be using.

E.g. Unless you are a frequent user of Social Networking sites, you cannot be a good developer if you want to do some development related to Social Networking

5) 3 things to keep learning - programming languages/frameworks, company specific framework,  Domain
Knowledge of the various programming tools (e.g. Ruby/Rails) we will be using daily is the bare minimum.
Apart from the above, usually every company has some specific frameworks that they have built for themselves. We have to learn that too.
Once we have enough technology knowledge, we can start to contribute towards solving Business Problems (of all sizes). Solving Business Problems however needs Domain Knowledge too. So we have to try to learn that as well.

6) Courage to learn at your own pace
It is sometimes very disheartening when we struggle to learn something new.
During those times, it takes a great deal of courage to still continue, and not give up.
We have to remember that learning slowly is infinitely better than completely giving up.
Giving up temporarily is ok - recharge and try again.
This is very important because, as developers, we have to learn continuously.

7) Screw Office Politics & Discussions to improve Process
This final point is an opinion and not a general rule like the above 1-6 rules.

Process, People-Management are important to any company and some people do have to worry about such headaches.
If that is not your cup of tea, always be on your guard to not get into those things, because such things are a daily reality for any company.

Seemingly-Harmless-Gossip is prevalent in every company and can have serious effects on people's careers if indulged in too much.

Office Gossip - Not OK;  Other Gossip - OK
Process Discussions - Not OK; Technology Discussions - OK

Motivation vs Discipline


"Screw motivation, what you need is discipline."
Part 2 - Practical Discipline - http://www.wisdomination.com/practical-discipline/

Thursday, April 27, 2017

Monday, April 10, 2017

jquery: dropdown

http://stackoverflow.com/questions/2780566/get-selected-value-of-a-dropdowns-item-using-jquery

For single select dom elements, to get the currently selected value:
$('#dropDownId').val();
To get the currently selected text:
$('#dropDownId :selected').text();

Sunday, April 9, 2017

UXDD - UX Driven Design

https://msdn.microsoft.com/en-us/magazine/mt619988.aspx
https://app.pluralsight.com/library/courses/ux-driven-software-design/table-of-contents

Excerpts:
"puts UX at the foundation of the entire design process."
"From a functional perspective, you can successfully build a working system regardless of whether you start the design effort from the bottom (say, from the persistence model) or the top (say, from presentation layer and view model). From a UX perspective, you can only be successful if you start designing from presentation and view models and build everything else, including the back-end stack, from there."
 "I learned from UX experts that requirements are better actively generated through evidence-based discussion than passively infer­red via interviews"
"Very few tasks are entirely accomplished through a single screen that you can summarize effectively to a wireframe. Just looking into the wireframe of a screen may not be enough to spot possible bottle­necks of the process implementation. Concatenating screens in a storyboard is a much better idea. In this regard, the biggest challenge I see is finding the tools to build storyboards."
 "... simply outsourcing the presentation layer to a team of UX experts isn’t enough. The presentation layer today is the most important part of a system and must result from the combined effort of solution architects, UX architects and customers. This must be the first step and ideally you move on only when the customer signs off on the presentation."
Figure 2 Tools for Quick and Effective UI Prototyping
ToolURL
Axureaxure.com
Balsamiqbalsamiq.com
Indigo Studioinfragistics.com/products/indigo-studio
JustInMindjustinmind.com
UXPinuxpin.com
Not sure why https://www.invisionapp.com/ was not mentioned in his article above.
It is being used by designers in our company and it seems to be pretty good.

Saturday, April 8, 2017

The Churn - No point discussing/fighting it

From what I have seen, companies just seem to want/require/need Change from time to time.

They end up restructuring their team(s). 'Reorg' is an often heard term.
Or they want their technology stack to change.
Or they want to bring in new Processes.
Or they bring in new people, fire some old ones, etc. etc. etc.

Depending on luck, individuals like me can get caught up in the politics of it or not.

Questions like "Are these changes required? Are they fair/correct?" come to mind and discussions inevitably take place between colleagues and we all feel miserable for a long period of time.

I have not been able to describe this phenomenon previously, but after hearing about 'The Churn' in an episode in The Expanse, I finally got convinced that this is it.

Excerpt from blog https://medium.com/anomalous-engineering/welcome-to-the-churn-5c201b3e9759 explaining what 'The Churn' is:

"When the jungle tears itself down and builds itself into something new."
...
"Some things are so fundamental that you can only survive them, or not"
...
"Until the Churn settles into whatever the fuck the New Normal becomes, we could be the looters, or the volunteers stopping them, or victims, or just bystanders"

And to maximize our chances of survival, the below blog suggests we should make ourselves 'deserving' of survival.

The Churn is inevitable, so there is no point in wasting time & energy in discussing it. It's better to use that time & energy to become more 'deserving' of survival.

As programmers, team-members, how can we become more 'deserving' of survival?

2 things come to mind:
1) by continuously putting in effort to improve our skills
2) by continuously putting in effort to be nice/fair to our colleagues

Next time, I am tempted to discuss 'stuff' about The Churn, I will try to remind myself - "It's The Churn man... There is no point in discussing/fighting it"

(The Churn - https://medium.com/anomalous-engineering/welcome-to-the-churn-5c201b3e9759)

Wednesday, March 29, 2017

Ruby related: Inspecting methods, Getting Source Location

http://stackoverflow.com/questions/4664578/how-do-i-inspect-the-methods-of-a-ruby-object
obj.class.instance_methods(false)

http://stackoverflow.com/questions/3393096/how-can-i-get-source-code-of-a-method-dynamically-and-also-which-file-is-this-me

 Use source_location:
class A
  def foo
  end
end
file, line = A.instance_method(:foo).source_location
# or
file, line = A.new.method(:foo).source_location
puts "Method foo is defined in #{file}, line #{line}"
# => "Method foo is defined in temp.rb, line 2"

Saturday, March 25, 2017

Modules vs Microservices

https://www.oreilly.com/ideas/modules-vs-microservices
https://www.reddit.com/r/programming/comments/61f13z/modules_vs_microservices/

Excerpt:
Much has been said about moving from monoliths to microservices. Besides rolling off the tongue nicely, it also seems like a no-brainer to chop up a monolith into microservices. But is this approach really the best choice for your organization? It’s true that there are many drawbacks to maintaining a messy monolithic application. But there is a compelling alternative which is often overlooked: modular application development. In this article, we'll explore what this alternative entails and show how it relates to building microservices.

Monday, March 20, 2017

Rails - logger enhancements

https://github.com/jrochkind/formatted_rails_logger

FormattedRailsLogger
Monkey-patches Rails BufferedLogger (the standard Rails logger) to accept a formatter just like ruby Logger does. Provides a formatter that includes timestamp and severity in logs, while taking account of Rails habit of making space in the logfile by adding newlines to the beginning of log message.

What is hard to do using React.js compared to jQuery?

https://www.quora.com/What-is-hard-to-do-using-React-js-compared-to-jQuery

Just name a few that React is not good at

1. Async loading. Async loading is a must-have for Single Page App but React doesn't have a native support for Async loading.
2. Animation. You have to fall back to other library for animation.
3. Integration with other library. You don't want to rewrite all available cool library in React, do you?
 
When working with async loading, animation and integration with other jQuery library, you end up have too many work-around in your code and you can hardly call your framework React.

Followers

Blog Archive