Yeah!
Assuming everything will go well I will go to event "Sam Harris & Yuval Noah Harari - Understanding The Present" in San Francisco in Masonic :-)
I love Yuval Noah Harari books - "Sapiens" and "Homo Deus", I love Sam Harris podcast (to be honest I didn't read any of his books, I started Free Will, and listened to Waking Up).
And this event is near premier of newest book of Yuval Noah Harari :-)
So it should be interesting ;-)
Similar postsbeta
Me in SF Moma...
"Sapiens" is really interesting
I hate 6 o'clock....
When you should stop read a book?
Python yet another hero of SF book Seveneves
Sunday, July 29, 2018
Sunday, July 15, 2018
Programmers love to over complicate...
Did you notice that programming use to be easier?
10 or 20 years ago you were spending more time writing code than now?
It is true for me.
10 years ago I was coding at work in Java and JavaScript. We were using MyEclipse and SVN without branches.
My day was something like this:
- update sources from SVN on trunk,
- look for info about stories,
- code:
- write code,
- run code,
- update sources from SVN on trunk,
- commit code if it was ready in given part,
- update sources from SVN on trunk,
- commit code (still if it was ready)
This was easy.
We had in each moment almost the most current source version on our machines.
We didn't have any CI tooling, but each time you updated and tried to build, and something was failing you were sharing with this and was trying to fix problem.
Without special monitors showing CI results.
Each week we had manual weekly build (written in ANT!), and QAs were testing this version.
It was working.
It was fast.
It was stable.
How it looks usually now?
You are coding with Java and JavaScript + ReactJS + Webpack + Gradle/Maven + Nexus + whatever else + GIT/HG with tons of branches.
Your day looks something like this:
- update from master (or current release master),
- resolve conflicts,
- commit,
- test on your branch (but it may take too much time),
- push to your branch,
- wait for tests,
- in case of failing investigate,
- look for info about stories,
- code,
- write code,
- wait till it compile,
- run code and some tests,
- commit code
- push code,
- wait for tests,
- look why some UI tests are failing,
- run those tests again,
- and again,
- create pull request,
- notice that in the meantime somebody else commited to master code he or she was cooking by last 5 days on own branch,
- merge,
- commit,
- squash commits (because somebody will complain that you have multiple commits),
- push,
- LINT or PMD or Sonar complaining,
- yeah, not in your code, but you needed to change some legacy code in class with 6 kLOCs....,
- hack Lint/PMD/Sonar,
- commit,
- wait for tests,
- CI is slow,
- create ticket for restarting CI,
- you need to stop because you have one of Scrum meetings,
- CI works again!!!!,
- tests are failing,
- again UX tests
I may little exaggerate, but from my perspective it too often looks like this (in many companies).
It seems that developers want to make things more complicated.
Or maybe it works in this way that some people have good ideas and intentions, but those latter are half baked, or introduced only because...
In several companies I saw problem with Maven.
Maven was in HQ and in other sites it was too slow.
So it was always decision, big managerial action "we are doing our own Maven repo which will sync-up with master in HQ!".
This was done.
After some short time people started to realize that they don't see most recent SNAPSHOTs, but after tinkering with /etc/hosts and making repo name resolving to IP of this Maven repo in HQ everything was starting to work.
From this time, in 1st or 2nd day each of newly employed was instructed to do changes in /etc/hosts....
Why? Because everyone is able to read on StackOverflow or something similar about setuping copies of Maven, but configuration is not so trivial....
(I'm still amazed that in one of companies they were extensively using ActiveMQ, and tried even to configure backups... but after trying they realized that it was much more complicated to configure and maintain so they simply killed backup ActiveMQ server without even changing apps configuration....)
Similar postsbeta
Which language is fastest? ;-)
Google Buzz - let's mark some comments as not spam ;-) or how to unhide "hidden" comments ;-)
How to get negative number from size() in LinkedList in Java? ;-)
What sux in G1?
Calculation of SSD life time in EEE PC
10 or 20 years ago you were spending more time writing code than now?
It is true for me.
10 years ago I was coding at work in Java and JavaScript. We were using MyEclipse and SVN without branches.
My day was something like this:
- update sources from SVN on trunk,
- look for info about stories,
- code:
- write code,
- run code,
- update sources from SVN on trunk,
- commit code if it was ready in given part,
- update sources from SVN on trunk,
- commit code (still if it was ready)
This was easy.
We had in each moment almost the most current source version on our machines.
We didn't have any CI tooling, but each time you updated and tried to build, and something was failing you were sharing with this and was trying to fix problem.
Without special monitors showing CI results.
Each week we had manual weekly build (written in ANT!), and QAs were testing this version.
It was working.
It was fast.
It was stable.
How it looks usually now?
You are coding with Java and JavaScript + ReactJS + Webpack + Gradle/Maven + Nexus + whatever else + GIT/HG with tons of branches.
Your day looks something like this:
- update from master (or current release master),
- resolve conflicts,
- commit,
- test on your branch (but it may take too much time),
- push to your branch,
- wait for tests,
- in case of failing investigate,
- look for info about stories,
- code,
- write code,
- wait till it compile,
- run code and some tests,
- commit code
- push code,
- wait for tests,
- look why some UI tests are failing,
- run those tests again,
- and again,
- create pull request,
- notice that in the meantime somebody else commited to master code he or she was cooking by last 5 days on own branch,
- merge,
- commit,
- squash commits (because somebody will complain that you have multiple commits),
- push,
- LINT or PMD or Sonar complaining,
- yeah, not in your code, but you needed to change some legacy code in class with 6 kLOCs....,
- hack Lint/PMD/Sonar,
- commit,
- wait for tests,
- CI is slow,
- create ticket for restarting CI,
- you need to stop because you have one of Scrum meetings,
- CI works again!!!!,
- tests are failing,
- again UX tests
I may little exaggerate, but from my perspective it too often looks like this (in many companies).
It seems that developers want to make things more complicated.
Or maybe it works in this way that some people have good ideas and intentions, but those latter are half baked, or introduced only because...
In several companies I saw problem with Maven.
Maven was in HQ and in other sites it was too slow.
So it was always decision, big managerial action "we are doing our own Maven repo which will sync-up with master in HQ!".
This was done.
After some short time people started to realize that they don't see most recent SNAPSHOTs, but after tinkering with /etc/hosts and making repo name resolving to IP of this Maven repo in HQ everything was starting to work.
From this time, in 1st or 2nd day each of newly employed was instructed to do changes in /etc/hosts....
Why? Because everyone is able to read on StackOverflow or something similar about setuping copies of Maven, but configuration is not so trivial....
(I'm still amazed that in one of companies they were extensively using ActiveMQ, and tried even to configure backups... but after trying they realized that it was much more complicated to configure and maintain so they simply killed backup ActiveMQ server without even changing apps configuration....)
Similar postsbeta
Which language is fastest? ;-)
Google Buzz - let's mark some comments as not spam ;-) or how to unhide "hidden" comments ;-)
How to get negative number from size() in LinkedList in Java? ;-)
What sux in G1?
Calculation of SSD life time in EEE PC
Monday, July 9, 2018
When you should stop read a book?
I like to read, and from more than year I try to spend daily at least 45 minutes reading some popular science or similar book.
But sometimes I don't like the book.
And I'm looking for some "formula" to decide if I should stop to read or not.
I already spend this time, and I'm not able to recoup it, still I may try to rescue rest of time I would spent reading....
So maybe something like:
expected_value = value_till_now/time_spent
This will let me estimate how much I may gain.
Interesting fact, because at the beginning I have some "value" already at least from this that reading on its own improves vocabulary and so on, at the beginning expected_value is almost infinite ;-)
Now is problem of this what should be expected_value.
I would propose something radical, expected value should be at least equal to average value from previously read books.
Let even be nicer for book, lets say it should be at least half of value of average book.
So formula to make decision should be:
stop_reading = value_till_now/time_spent < 0.5*average_value_of_book
It seems also that using this formula will cause that reading more books will means stoping earlier with bad books ;-)
And thanks to this I avoided in last year or so reading books like:
The Singularity Is Near by Ray Kurzweil - topic was interesting, but at least Polish translation of this book was so badly written that I didn't wanted to read it,
Getting Things Done by David Allen - how many times the same may be written? Or maybe this was again Polish translation,
The 4-Hour Workweek by Tim Ferriss - I admire Tim Ferriss for creating really good idea of making business - let others do it - it brillant idea, and books created in such way like Tools of Titans, and Mentors Tribe are quiet interesting, this one is simply boring.
Capital in the Twenty-First Century by Thomas Piketty - main idea of book is worth noting, but it isn't easy read, and one simply don't have way to verify data provided, so instead of reading this one book I would prefer reading some summary of it (from this what I heard the same is true about Marx's Capital ;-))
Similar postsbeta
Python yet another hero of SF book Seveneves
How to detect clickbaits?
Recursion is evil ;-)
It's alive... still ;-)
How to get negative number from size() in LinkedList in Java? ;-)
But sometimes I don't like the book.
And I'm looking for some "formula" to decide if I should stop to read or not.
I already spend this time, and I'm not able to recoup it, still I may try to rescue rest of time I would spent reading....
So maybe something like:
expected_value = value_till_now/time_spent
This will let me estimate how much I may gain.
Interesting fact, because at the beginning I have some "value" already at least from this that reading on its own improves vocabulary and so on, at the beginning expected_value is almost infinite ;-)
Now is problem of this what should be expected_value.
I would propose something radical, expected value should be at least equal to average value from previously read books.
Let even be nicer for book, lets say it should be at least half of value of average book.
So formula to make decision should be:
stop_reading = value_till_now/time_spent < 0.5*average_value_of_book
It seems also that using this formula will cause that reading more books will means stoping earlier with bad books ;-)
And thanks to this I avoided in last year or so reading books like:
The Singularity Is Near by Ray Kurzweil - topic was interesting, but at least Polish translation of this book was so badly written that I didn't wanted to read it,
Getting Things Done by David Allen - how many times the same may be written? Or maybe this was again Polish translation,
The 4-Hour Workweek by Tim Ferriss - I admire Tim Ferriss for creating really good idea of making business - let others do it - it brillant idea, and books created in such way like Tools of Titans, and Mentors Tribe are quiet interesting, this one is simply boring.
Capital in the Twenty-First Century by Thomas Piketty - main idea of book is worth noting, but it isn't easy read, and one simply don't have way to verify data provided, so instead of reading this one book I would prefer reading some summary of it (from this what I heard the same is true about Marx's Capital ;-))
Similar postsbeta
Python yet another hero of SF book Seveneves
How to detect clickbaits?
Recursion is evil ;-)
It's alive... still ;-)
How to get negative number from size() in LinkedList in Java? ;-)
Sunday, July 1, 2018
Blindfold programming
Some time ago I read this article, and started to play with idea of Blindfold programming.
What this whole Blindfold Programming is about?
It is about trying to write code in your head, without any screen, keyboard, paper or whiteboard. Only in head.
Why?
To exercise :-)
Not used ability usually stops to work...
And in my case I noticed several years ago what becoming more senior in software engineering in my case means writing less code... but still coding is very important part of this job, so it is important to practice :-)
Additionally it seems that it helps with chunking. and naturally leads to dividing problem to smaller subproblems.
This part is important, because human brain doesn't have too much space in short memory. One is able to keep in the same time ~4 things in memory and focus.
So from some time I'm going to LeetCode easy problems and I'm trying to write whole solution in my head. Sometimes I'm touching also medium problems in the same way.
Next, sometimes I'm writing code on whiteboard or with pencile on my iPad Pro, but usually I simply put whole code from my head to LeetCode editor and I'm checking if my solution works ;-)
And after several months of doing it I think I can see some improvements ;-)
Similar postsbeta
Coding without IDE
Whiteboard
Coursera courses - worth of doing?
My way to (parital) vegetarianism
Programmers love to over complicate...
What this whole Blindfold Programming is about?
It is about trying to write code in your head, without any screen, keyboard, paper or whiteboard. Only in head.
Why?
To exercise :-)
Not used ability usually stops to work...
And in my case I noticed several years ago what becoming more senior in software engineering in my case means writing less code... but still coding is very important part of this job, so it is important to practice :-)
Additionally it seems that it helps with chunking. and naturally leads to dividing problem to smaller subproblems.
This part is important, because human brain doesn't have too much space in short memory. One is able to keep in the same time ~4 things in memory and focus.
So from some time I'm going to LeetCode easy problems and I'm trying to write whole solution in my head. Sometimes I'm touching also medium problems in the same way.
Next, sometimes I'm writing code on whiteboard or with pencile on my iPad Pro, but usually I simply put whole code from my head to LeetCode editor and I'm checking if my solution works ;-)
And after several months of doing it I think I can see some improvements ;-)
Similar postsbeta
Coding without IDE
Whiteboard
Coursera courses - worth of doing?
My way to (parital) vegetarianism
Programmers love to over complicate...
Subscribe to:
Posts (Atom)
