Friday, June 30, 2017
A progressive Web application with Vue JS, Webpack & Material Design
A progressive Web application with Vue JS, Webpack & Material Design
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
Wednesday, June 28, 2017
Create a Simple ToDo App with Expressjs
Create a Simple ToDo App with Expressjs - http://www.coderew.com/tech/todo-app-expressjs/
Sunday, June 25, 2017
Tuesday, June 20, 2017
Sunday, June 18, 2017
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.
Thursday, June 15, 2017
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/
https://www.reddit.com/r/movies/comments/67qzrx/hello_reddit_i_am_actor_and_artist_val_kilmer_i/
CatchMeKillMe 243 points244 points245 points (23 children)[–]OfficialValKilmerVal Kilmer[S] 1413 points1414 points1415 points (22 children)
Saturday, June 10, 2017
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
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:
- 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
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
- 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:
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.
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.
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
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
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
Thursday, June 8, 2017
Rails performance related: ScoutApm gem
ScoutApmA Ruby gem for detailed Rails application performance analysis. Metrics are reported to Scout, a hosted application monitoring service.
Rails performance related: Speeding Up Rendering Rails Pages with render_async
Speeding Up Rendering Rails Pages with render_async
https://semaphoreci.com/blog/2017/06/08/speeding-up-rails-pages-with-render-async.html
https://semaphoreci.com/blog/2017/06/08/speeding-up-rails-pages-with-render-async.html
Sunday, June 4, 2017
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.
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:
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.
Subscribe to:
Posts (Atom)