ReactXP - https://microsoft.github.io/reactxp/
React Native for Web - https://github.com/necolas/react-native-web
React Native for Web - https://github.com/necolas/react-native-web
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.
Thursday, June 1, 2017
Sunday, May 28, 2017
Saturday, May 27, 2017
yap-json
https://github.com/cesarferreira/yap-json
Pipe your
curl -s https://api.github.com/users/cesarferreira | yap-json
Pipe your
json into yap-json to make it prettycurl -s https://api.github.com/users/cesarferreira | yap-json
git: View changes in last commit of a file
https://stackoverflow.com/questions/10176601/git-diff-file-against-its-last-change
See last commit's changes: git log -p -1 filename
See last 2 commits' changes: git log -p -2 filename
See last commit's changes: git log -p -1 filename
See last 2 commits' changes: git log -p -2 filename
Tuesday, May 23, 2017
Monday, May 22, 2017
Mavo - A new, approachable way to create Web applications
http://mavo.io/
Mavo helps you turn your static HTML into reactive web applications without a single line of programming code and no server backend.
Developed in the Haystack Group at MIT CSAIL and led by Lea Verou.
Mavo helps you turn your static HTML into reactive web applications without a single line of programming code and no server backend.
Developed in the Haystack Group at MIT CSAIL and led by Lea Verou.
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.
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.
The Future of Advertising: Brave and the Basic Attention Token
The Future of Advertising: Brave and the Basic Attention Token
http://sinahab.com/blog/basic-attention-token/
https://basicattentiontoken.org/
https://basicattentiontoken.org/wp-content/uploads/2017/05/BasicAttentionTokenWhitePaper.pdf
http://sinahab.com/blog/basic-attention-token/
https://basicattentiontoken.org/
https://basicattentiontoken.org/wp-content/uploads/2017/05/BasicAttentionTokenWhitePaper.pdf
Saturday, May 20, 2017
Sleep Sort
Found the below here - https://www.quora.com/What-is-the-strangest-sorting-algorithm
I implemented it in javascript below:
JS Bin on jsbin.com
Thursday, May 18, 2017
Saturday, May 13, 2017
ElasticSearch + Ruby-on-Rails
ElasticSearch with Ruby-on-Rails
https://www.pluralsight.com/guides/ruby-ruby-on-rails/elasticsearch-with-ruby-on-rails
https://www.pluralsight.com/guides/ruby-ruby-on-rails/elasticsearch-with-ruby-on-rails
Friday, May 12, 2017
Thursday, May 11, 2017
Tuesday, May 9, 2017
Monday, May 8, 2017
Web Application - Kiosk project
Web Application - Kiosk project
Hide Address Bar:
http://stackoverflow.com/a/38853861/637563
Send a custom header:
http://infoheap.com/chrome-add-custom-http-request-headers/
http://stackoverflow.com/questions/7115304/is-there-a-google-chrome-extension-to-inject-custom-http-headers-in-each-request
To create an extension in chrome similar to above:
https://developer.chrome.com/extensions/webRequest
Hide Address Bar:
http://stackoverflow.com/a/38853861/637563
Send a custom header:
http://infoheap.com/chrome-add-custom-http-request-headers/
http://stackoverflow.com/questions/7115304/is-there-a-google-chrome-extension-to-inject-custom-http-headers-in-each-request
To create an extension in chrome similar to above:
https://developer.chrome.com/extensions/webRequest
Sunday, May 7, 2017
7 Awesome Emmet HTML Time-Saving Tips
https://designshack.net/articles/css/7-awesome-emmet-html-time-saving-tips/
https://github.com/sergeche/emmet-sublime
Go to Matching Pair – ⇧⌃T / Ctrl+Alt+J
Wrap With Abbreviation — ⌃W / Shift+Ctrl+G
https://github.com/sergeche/emmet-sublime
Go to Matching Pair – ⇧⌃T / Ctrl+Alt+J
Wrap With Abbreviation — ⌃W / Shift+Ctrl+G
Friday, May 5, 2017
Sunday, April 30, 2017
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.
'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
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
Saturday, April 22, 2017
Monday, April 17, 2017
Subtime Text related: Useful plugins
The following have been invaluable plugins to me:
Git Gutter
MoveTab
Git Gutter
MoveTab
Sunday, April 16, 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:
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:
It is being used by designers in our company and it seems to be pretty good.
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 inferred 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 bottlenecks 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 PrototypingNot sure why https://www.invisionapp.com/ was not mentioned in his article above.
Tool URL Axure axure.com Balsamiq balsamiq.com Indigo Studio infragistics.com/products/indigo-studio JustInMind justinmind.com UXPin uxpin.com
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)
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, April 5, 2017
H-1B: Memo clarifying USCIS practice says employers must show the job is a specialty occupation
H-1B Visas for Computer Programmers May Be Harder to Come By
https://www.shrm.org/resourcesandtools/hr-topics/talent-acquisition/pages/computer-programmers-may-need-to-fight-to-get-h-1b-visas-as-usual.aspx
Memo clarifying USCIS practice says employers must show the job is a specialty occupation
https://www.shrm.org/resourcesandtools/hr-topics/talent-acquisition/pages/computer-programmers-may-need-to-fight-to-get-h-1b-visas-as-usual.aspx
Tuesday, April 4, 2017
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
http://stackoverflow.com/questions/3393096/how-can-i-get-source-code-of-a-method-dynamically-and-also-which-file-is-this-me
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
endfile, 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"
Tuesday, March 28, 2017
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:
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
FormattedRailsLoggerMonkey-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.
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.
Sunday, March 19, 2017
Turbolinks, jquery-pjax - Alternatives to client-side SPA frameworks
https://github.com/turbolinks/turbolinks
https://github.com/defunkt/jquery-pjax
These are alternatives to using client-side JS frameworks for building SPAs.
https://github.com/defunkt/jquery-pjax
These are alternatives to using client-side JS frameworks for building SPAs.
Saturday, March 18, 2017
RxJS, Most.js, xstream
Libraries like xstream, RxJS or Most.js, greatly simplify code related to events, asynchrony, and errors.
http://reactivex.io/rxjs/manual/tutorial.html
https://github.com/cujojs/most/
https://github.com/staltz/xstream
Comparing RxJS and xstream: from https://medium.com/@AlbertKlusky/rxjs-be-careful-with-that-axe-eugene-a1763d115e30#.fmw8sa3au
http://reactivex.io/rxjs/manual/tutorial.html
https://github.com/cujojs/most/
https://github.com/staltz/xstream
Comparing RxJS and xstream: from https://medium.com/@AlbertKlusky/rxjs-be-careful-with-that-axe-eugene-a1763d115e30#.fmw8sa3au
I relay like rxjs. It’s very powerful tools, but at the same time it’s super dangerous. I know that creator of framework Cycle.js — André Staltz — resigned from using Rxjs and switched to xstreams. Main problem which forced him to switch to xstream was confusion around hot and cold observables. I think the same. Rxjs would be much easier without cold observable, if everything would be hot like with xstreams. Cold streams are handy but are super dangerous. Similar like with two way data binding. It’s cool feature, but super dangerous.
quokkajs - The Live Scratchpad for JavaScript
The Live Scratchpad for JavaScript
https://quokkajs.com/
(To be used with VS Code)
Getting Started: https://quokkajs.com/docs/index.html#getting-started
https://quokkajs.com/
(To be used with VS Code)
Getting Started: https://quokkajs.com/docs/index.html#getting-started
ViaJS - A JavaScript library that allows you to load HTML content dynamically
ViaJS - A JavaScript library that allows you to load HTML content dynamically
https://github.com/abdi0987/ViaJS
This seems like a simple library to learn and use. (Have to try it out)
https://github.com/abdi0987/ViaJS
This seems like a simple library to learn and use. (Have to try it out)
Friday, March 17, 2017
ES6 - const (for objects and arrays)
Excerpt from https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const
// const also works on objects
const MY_OBJECT = {'key': 'value'};
// Attempting to overwrite the object throws an error
MY_OBJECT = {'OTHER_KEY': 'value'};
// However, object keys are not protected,
// so the following statement is executed without problem
MY_OBJECT.key = 'otherValue'; // Use Object.freeze() to make object immutable
// The same applies to arrays
const MY_ARRAY = [];
// It's possible to push items into the array
MY_ARRAY.push('A'); // ["A"]
// However, assigning a new array to the variable throws an error
MY_ARRAY = ['B']
Thursday, March 16, 2017
React related - Redux vs Mobx
https://www.reddit.com/r/reactjs/comments/4npzq5/confused_redux_or_mobx/
Has comments, from authors of Redux and Mobx, that serve as concise intros to each of them.
Has comments, from authors of Redux and Mobx, that serve as concise intros to each of them.
Monday, March 13, 2017
ES6 - What do function parameter lists inside of curly braces do in es6?
const func = ({ param1, param2 }) => {
//do stuff
}
It is destructuring, but contained within the parameters. The equivalent without the destructuring would be:
const func = o => {
var param1 = o.param1;
var param2 = o.param2;
//do stuff
}
It is basically shorthand for
{param1: param1, param2: param2}Wednesday, March 8, 2017
Tuesday, March 7, 2017
Saturday, March 4, 2017
Code Reviews
http://monotonically-unstable.github.io/programming/2017/03/03/methodical_code_reviews/
Excerpt:
Excerpt:
Whenever I trained a new team member on how to do code reviews, I instructed two major rules. In short, they went along these lines:
- Never make the other person feel bad about his/her work.
- Never give a review note that is based on a gut feeling.
Friday, March 3, 2017
Saturday, February 25, 2017
Tuesday, February 21, 2017
Monday, February 20, 2017
Mithril
A simple application where we can list users from a server and edit them individually
http://mithril.js.org/simple-application.html
http://mithril.js.org/simple-application.html
REM: REST API for Prototyping from Heroku
http://rem-rest-api.herokuapp.com/
REM is a REST API for prototyping. It accepts JSON requests, returns JSON responses and persists data between requests like a real API. But your test data is only visible to you. It's CORS enabled and no API key is required.
var xhr = new XMLHttpRequest() xhr.open("GET", "http://rem-rest-api.herokuapp.com/api/users", true) xhr.withCredentials = true xhr.send() xhr.onload = function() { var data = JSON.parse(xhr.responseText) }
Friday, February 17, 2017
ES6 - Arrow Functions
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions
https://hacks.mozilla.org/2015/06/es6-in-depth-arrow-functions/
Syntax
Basic Syntax
(param1, param2, …, paramN) => { statements } (param1, param2, …, paramN) => expression // equivalent to: (param1, param2, …, paramN) => { return expression; } // Parentheses are optional when there's only one parameter: (singleParam) => { statements } singleParam => { statements } // A function with no parameters requires parentheses: () => { statements } () => expression // equivalent to: () => { return expression; }Advanced Syntax
// Parenthesize the body to return an object literal expression: params => ({foo: bar}) // Rest parameters and default parameters are supported (param1, param2, ...rest) => { statements } (param1 = defaultValue1, param2, …, paramN = defaultValueN) => { statements } // Destructuring within the parameter list is also supported var f = ([a, b] = [1, 2], {x: c} = {x: a + b}) => a + b + c; f(); // 6Detailed syntax examples can be seen here.
Saturday, February 11, 2017
Friday, February 10, 2017
Ajax and React
http://andrewhfarmer.com/react-ajax-best-practices/
https://daveceddia.com/ajax-requests-in-react/
Excerpt:
One of the first questions new React developers have is, “How do I do AJAX requests in React?”Here’s an answer to that question.
First: React itself doesn’t have any allegiance to any particular way of fetching data. In fact, as far as React is concerned, it doesn’t even know there’s a “server” in the picture at all.React simply renders components, using data from only two places: props and state.
So therefore, to use some data from the server, you need to get that data into your components’ props or state.
You can complicate this process with services and data models (er, “build abstractions”) as much as you desire, but ultimately it’s just components rendering props and state.
Sunday, February 5, 2017
Kweb
KWeb is a library for building rich interactive web applications in pure Kotlin that makes the distinction between web browser and server largely invisible to the programmer.Kweb the new coroutines mechanism in upcoming Kotlin 1.1 to elegantly avoid callback hell.Kweb also incorporates a simple DSL for manipulating the browser’s DOM, and plugins to allow you to use popular JavaScript frameworks like JQuery and Material Design Light. It’s also surprisingly easy to add your own plugin for your favorite library or tool.
Importance of hard work
http://www.usatoday.com/story/sports/nfl/patriots/2017/02/04/new-england-dynasty-super-bowl-xxxvi-rams-bill-belichick-tom-brady/97488880/
“Our standard is high. We always talk that whatever we achieve is going to be earned on the practice field and earned in a lot of different times throughout the course of the season when we may not have a crowd of people watching us.
"We try to pay for it in advance. Over the years, that hasn’t changed.”
Thursday, February 2, 2017
Monday, January 30, 2017
git-recall
https://github.com/Fakerr/git-recall/
Purpose
git-recallis a simple tool that allows you to easily go through your commits and check what you or other contributors in your team did. It doesn't aim to be a replacement for thegit logcommand, but just to be a handy way to recall what you've done from your terminal.
Introduce process only as a last resort
https://medium.com/@yanismydj/introduce-process-only-as-a-last-resort-21bd25e53eb#.csf89ikjm
Excerpt:
Excerpt:
Introduce process only as a last resort
Lately, I’ve been thinking a lot about how organizations love process. Having systems and process can be very important. Without them, lines can be blurred, slopes become slippery, and maintaining consistency becomes very difficult. That being said, process is also toxic and dangerous to startups, especially at the early stages. When rules & process are introduced, you limit people’s autonomy, and chip away at the critical thinking and common sense that is required of them everyday.
Saturday, January 28, 2017
Comparing Elixir and Go
https://blog.codeship.com/comparing-elixir-go/
Excerpt:
Excerpt:
For very focused code, portable system level tools, performance intensive tasks, and APIs, Go is very hard to beat. For full-stack web applications, distributed systems, real-time systems, or embedded applications, I’d reach for Elixir.
Sunday, January 22, 2017
Wednesday, January 18, 2017
Thursday, December 22, 2016
Saturday, December 17, 2016
Friday, December 9, 2016
Thursday, December 8, 2016
Monday, December 5, 2016
Vue.js in GitLab
- This is a good talk to watch for info regarding Why Gitlab chose Vue, How they are using Vue etc.
- Gitlab is using Rails, so it should have important/useful lessons for Vibe
- Gitlab is using Rails, so it should have important/useful lessons for Vibe
Wednesday, November 30, 2016
Sunday, November 27, 2016
Turbolinks related
https://changelog.com/posts/why-we-chose-turbolinks
This is the 2nd blog-post i noticed that mentions using Turbolinks with Phoenix. And they also chose Turbolinks over current JS frameworks like React, Angular.
The previous one - http://psjp-learn.blogspot.in/2016/07/phoenix-turbolinks-as-replacement-for.html
This is the 2nd blog-post i noticed that mentions using Turbolinks with Phoenix. And they also chose Turbolinks over current JS frameworks like React, Angular.
The previous one - http://psjp-learn.blogspot.in/2016/07/phoenix-turbolinks-as-replacement-for.html
Microservices Migration: Lessons Learned
https://medium.com/technology-learning/microservices-migration-lessons-learned-f84166ec7eb0#.spcg7hoj8
Apart from the content of the blogpost, it has useful links to other articles.
Apart from the content of the blogpost, it has useful links to other articles.
Saturday, November 26, 2016
Monday, November 14, 2016
Wednesday, November 9, 2016
Monday, November 7, 2016
.Net related - Jason Robert - Microsoft MVP and Author's Blog
http://dontcodetired.com/blog
- this seems to be a blog to follow
- this seems to be a blog to follow
Sunday, November 6, 2016
The Difference Between Throttling and Debouncing
https://css-tricks.com/the-difference-between-throttling-and-debouncing/
Above link shows a nice demo of how many Scroll Events are generated when using Nothing vs Throttling vs Debouncing
Above link shows a nice demo of how many Scroll Events are generated when using Nothing vs Throttling vs Debouncing
Friday, November 4, 2016
Thursday, November 3, 2016
Monday, October 31, 2016
Sunday, October 23, 2016
Multi-Processing, Multi-Threading, Synchronization
Multi-Processing, Multi-Threading, Synchronization
https://techtake.info/2016/10/13/symmetric-multi-processing-multi-threading-and-synchronisation-explained/
https://techtake.info/2016/10/13/symmetric-multi-processing-multi-threading-and-synchronisation-explained/
Subscribe to:
Posts (Atom)