Articles

Reading diary

Article Title Link Date Read Notes  
Burning Out https://www.phparch.com/2018/10/the-dev-lead-trenches-burning-out/ 2019-08-03 Very interesting, giving symptoms, suggested solns and links with depression  
blah1 blah1 blah1 blah1 blah1 blah1

Utilities

List of Articles

AI

Agile

Lucene + SOLR

Architecture + Craftsmanship stuff

  Amazon vs Google - https://plus.google.com/+RipRowan/posts/eVeouesvaVX
  http://www.infoq.com/presentations/groovy-plugin-dsl
  http://www.infoq.com/presentations/spring-app-security
  http://en.wikipedia.org/wiki/Liskov_substitution_principle
  http://en.wikipedia.org/wiki/Design_Patterns
  http://architects.dzone.com/articles/solr-hadoop-big-data-love
  http://static.googleusercontent.com/media/research.google.com/fr//pubs/archive/38331.pdf
  https://www.coursera.org/course/thinkagain - arguing and reasoning course
  http://www.comp.nus.edu.sg/~stevenha/visualization/ visualising algorithms
  https://www.youtube.com/watch?v=uhkM3aPvH28 SophiaConf2015 - O. Tavard (France Labs) - Les Big Data Science facile par l'angle de la fouille
  Martin fowler refactoring workflow https://www.youtube.com/watch?v=vqEg37e4Mkw
  Sandro Macuso refactoring - https://www.youtube.com/watch?v=JTHMd1nQlSg
  Agile: The Good, The Hype, and the Ugly" by Bertrand Meyer. 
  http://blog.agiledeveloper.com/
  https://medium.com/@aboodman/in-march-2011-i-drafted-an-article-explaining-how-the-team-responsible-for-google-chrome-ships-c479ba623a1b#.s88ghesta
  The death of continuous integration - https://www.youtube.com/watch?v=q-dPdpxIcZQ
  http://monospacedmonologues.com/post/138268503035/moving-parts - very interesting series from Samir
  Related to above -> https://www.cs.helsinki.fi/u/luontola/tdd-2009/ext/ObjectCalisthenics.pdf
  http://blog.codinghorror.com/the-ultimate-code-kata/
  http://williamdurand.fr/2013/07/30/from-stupid-to-solid-code/ - STUPID vs SOLID v. good
  http://gb-prod.fr/2016/06/12/artisan-developpeur.html
  http://williamdurand.fr/2013/06/03/object-calisthenics/#9-no-getters/setters/properties
  4 Rules of simple design - http://martinfowler.com/bliki/BeckDesignRules.html
  Code Reviews - https://www.kevinlondon.com/2015/05/05/code-review-best-practices.html
  Why I studied for 8 months for Google interview - https://medium.freecodecamp.com/why-i-studied-full-time-for-8-months-for-a-google-interview-cc662ce9bb13#.x7emmmbds
  Code Empathy - http://codingwithempathy.com/ - nice articles about human side of code review etc. 
  Arlo Belshee - Refactoring - http://arlobelshee.com/the-core-6-refactorings/#more-243
  Arlo Belshee - DRY vs WET - Write explicit tests - http://arlobelshee.com/wet-when-dry-doesnt-apply/#more-239 - Domain Driven Design - file:///home/dcostello/Downloads/Mastering%20Strategic%20Domain-Driven%20Design%20-%20Maciej%20Jedrzejewski.pdf

Code Software Craftsmanship

  Uncle Bob's Tip #12 no boolean parameters - http://www.informit.com/articles/article.aspx?p=1392524

Books DS and Algo Analysis in Java - Mark Allen Weiss 2)Algorithms, 4th Edition

Data Science

Domain Specific Languages

  Martin Fowler on DSL - http://martinfowler.com/books/dsl.html
  http://en.wikipedia.org/wiki/Domain-specific_language
  http://www.javaworld.com/article/2077865/core-java/creating-dsls-in-java--part-1--what-is-a-domain-specific-language-.html

Javascript

  http://ianstormtaylor.com/rendering-views-in-backbonejs-isnt-always-simple/

parallax effect sites

  http://www.webdesign.org/how-to-create-a-parallax-scrolling-website.22336.html
  https://github.com/Prinzhorn/skrollr
  http://prinzhorn.github.io/skrollr/
  http://stephband.info/jparallax/
  http://untame.net/2013/04/how-to-integrate-simple-parallax-with-twitter-bootstrap/
  http://mode87.com/untame/demo/parallax/
  Bootstrap alternative - Foundation Framework - http://foundation.zurb.com/

CSS stuff

  Less vs Sass - https://www.udemy.com/blog/less-vs-sass/
  www.zingdesign.com/less-vs-sass-its-time-to-switch-to-sass/
  css-tricks.com/sass-vs-less/
  http://learn.shayhowe.com/advanced-html-css/preprocessors/
  Nice feature of CSS3 description - http://tutorialzine.com/2013/10/12-awesome-css3-features-you-can-finally-use/
  https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS

JVM Languages

Scala

  Hello world Scala + Spring http://pivotallabs.com/spring-4-mvc-scala/
  Coursera -

Java

  http://doanduyhai.wordpress.com/2012/07/29/gwt-json-integration-with-spring-mvc/
  http://stackoverflow.com/questions/13375901/json-message-post-from-gwt-to-spring-mvc-controller
  http://www.infoq.com/articles/Open-JDK-and-HashMap-Off-Heap
  Concurrency - http://java-is-the-new-c.blogspot.ru/2014/01/comparision-of-different-concurrency.html
  Good Coding Guidlines - http://blog.rocketpoweredjetpants.com/2014/01/a-ranty-and-dogmatic-troll-masquerading.html
  http://lucene.apache.org/core/4_9_0/demo/overview-summary.html#overview_description
  http://www.lucenetutorial.com/basic-concepts.html
  https://leanpub.com/socra/packages/book/purchases/new
  Rest API documentation - https://helloreverb.com/developers/swagger
  Wireframeing for web apps - http://insideintercom.io/wireframing-for-web-apps/?utm_content=bufferccbc4&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
  MongoDB + Java - http://trishagee.github.io/post/getting_started_with_mongodb_and_java/
  http://shazsterblog.blogspot.fr/2014/11/java-8-not-paradigm-shift-just_12.html
  Certification Stuff http://jakubstas.com/oracle-certified-professional-java-programmer/
  http://www.java67.com/2013/06/how-get-method-of-hashmap-or-hashtable-works-internally.html
  http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b27/java/util/HashMap.java?av=f

Blogging Platform

  http://spf13.com/project/hugo

Kindle

  Article about storing non-amazon books for your library http://www.mobileread.com/forums/showthread.php?t=226851

PHP

  Analytics Platform - http://piwik.org/

Python

  http://simplyargh.blogspot.fr/2012/04/python-27-django-14-on-bluehost.html
  https://medium.com/cs-math/11-things-i-wish-i-knew-about-django-development-before-i-started-my-company-f29f6080c131

Android

Shortcuts Eclipse

Alt+Shift+X,T execute test Alt+Shift+D,T executes test in Ctrl+Shift+B - add breakpoint Ctrl+F11 - rerun last history

Alt + up and Alt + down - Shift a code block

Ctrl-Shift-M - imports, so to convert static call to static import

Coding Katas

  Prime Factors - https://github.com/alebaffa/codingdojo/tree/master/primefactors/python
  Game of Life - http://codingdojo.org/cgi-bin/index.pl?action=browse&diff=1&id=KataGameOfLife

Eclipse collections Stuff

  https://github.com/eclipse/eclipse-collections

Geek construction toys

https://www.wired.com/2016/10/5-great-toys-get-kids-brain-tickin/

Readme.MD viewer

https://github.com/joeyespo/grip

Regex Tester https://www.debuggex.com/

Writing an interpreter http://www.craftinginterpreters.com/?utm_content=buffereedae&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer http://www.craftinginterpreters.com/contents.html

Being a Tech Lead http://www.se-radio.net/2016/08/se-radio-episode-265-pat-kua-on-becoming-a-tech-lead/ http://www.thekua.com/

Conway's Law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. Fred Brooks cited the paper and the idea in his elegant classic "The Mythical Man-Month," calling it "Conway's Law." The name stuck.

Clean Code notes

Video 2 in the series

Very important and worth rewatching (and reading the chapter) Method and variable naming

  • Variable name - proportional to their scope - long lived, long name + vice versa
  • Method names + Class names - inverse proportional to their scope - e.g. want public stuff to have short simple names

Explaining Agile: Martin Fowler and Neil Ford talk 2013

YouTube Video: https://www.youtube.com/watch?v=GE6lbPLEAzc&list=WL&index=23

9:02 - paraphrase - Scrum often suffers from not implementing technical practices They take the project management stuff without taking the technical stuff

http://www.martinfowler.com/articles/designDead.html

Predictive vs Agile Process First vs People First

Neil Ford -> Communication > Technology "Communication trumps technology every time" – Example - Malawi - "Rapid SMS" - Python + Django - Helps detect disease outbreaks quickly in a country with little infrastructure or digitisation of information.

Fowler Defined Process vs Imperical Process - Feed back loops Example: Making Fruitcake vs (e.g. taking a shower in a strange hotel)

Tool - CC Board -> overview of lots of builds - TODO - what is this??????

Pair Programming - Navigator/Implementer

"Perfect is a VERB, NOT and adjective"

Closing phrase If we do XP the same as 1 year ago, we're not doing XP

Legacy Code: 7 tips for approaching code you didn't write | Vokal

Legacy Code: 7 tips for approaching code you didn't write Posted on June 19, 2015, written by Vince Mammana-Lupo

I was recently presented the opportunity to jump on a project that has been running for 6 years and is easily a thousand files strong. Much of my past engineering experience has been centered on smaller projects that I either created or had direct access to the person who did. Thus, I was a fish out of water inheriting a project of this magnitude. I am writing this post to pass down some words of advice so that your transition will be both productive and as painless as possible.

Embrace the Past

What's done is done. Getting frustrated over a specific implementation won't do you any good. There are tons of factors out of anyone's control that could've contributed to the current state of the project you have inherited. For example, maybe the developers were dealt a tight deadline, or they didn't have all the information they needed in time to make the architecture what it needed to be. We have all been there. It's best to adopt a constructive mindset and use inheriting legacy code as an opportunity to show what a great developer you are! If you can see issues in code other people have written, pat yourself on the back and remember: Don't Kick The Can.

Don't Kick The Can

When there are hundreds or thousands of files in a project, chances are you may never need to explore all of them. That said, if you are working in a file where you realize there are major "issues," don't kick the can. Make other team members aware of your concerns with the file in question. Again, at least let somebody know. If possible, make the improvements you can while you are working in that file. A solid practice would be to leave a well documented comment in areas of concern and creating corresponding tasks in the backlog to set aside designated time for improvement. You will make someone else's life easier when working in that file down the road.

Refactor, Test, Refactor

Making things better generally isn't easy, especially when you are working in a massive project where one file change comes with an avalanche of ramifications. That said, refactoring and writing tests is a great and proactive way of familiarizing yourself with the project that you inherited. The thought behind this is that to refactor and test a feature or specific implementation you will have to truly understand the behavior of the code and the issue the code is addressing. This process usually gets the developer diving into files he/she had no clue existed and will quickly improve your knowledge of "where things are happening."

New Feature? Pick Me! Pick Me

Let's be honest: inheriting legacy code is never easy. Even if you go at it with the best mindset, piecing together an understanding of someone else's thought process can be both very challenging and mentally draining. That's why it could work to your benefit to volunteer for building out new functionality. Nothing is better than the opportunity to start fresh. You will definitely feel rejuvenated contributing some well-written and well-documented code to a legacy project!

It's Ok to Bug Me

Developers usually loathe bug fixes. They carry a constant undertone of "busy work." However, taking on bug fixes can be another great way to gain exposure to a new code base. I was afforded the luxury to take on what were deemed "small" and "manageable" bugs at first. Small victories from squashing bugs furthered my understanding of many of the various features' architectures and provided me a channel to contribute to the rest of the team very quickly.

Documentation—Leave a Paper Trail

If you've inherited a legacy project, chances are you've experienced frustration over not understanding what the previous developer was trying to do. I pray you never see a 300-line method with high cyclomatic complexity and without any comments. Save yourself and others time down the road by writing well-documented comments for classes and methods. Let people know what method "X" should be used for so they don't have to waste time finding breadcrumbs and guessing at functionality.

Communication is Key

I have noticed that a huge contributor to success on a large legacy project is communication. Never be afraid to lean on your teammates. If you are working in a file or on a feature that a teammate built, do not hesitate to poll them with questions and try to understand their logic. It will definitely make things easier.

Notes from Sandro Mancuso Refactoring and Testing Legacy code

Tips

  Refactor from deepest to shallowest branch
  Test from shallowest to deepest branch

Writing Tests

  Should + sentence is a good way to write test names that validate behaviour and not a technical implementation - e.g. shouldValidateLoggedInUser and not getTripsByUser
  A Seam: a seam is where 2 classes meet. Often when you are writing test classes for legacy code, the seam between the class under test and its dependent class(es) is in the method being tested. 
      This is a problem and should be avoided by moving the seam to another method which can then be overridden from the test class and mocked. 
      E.g. a db connection call in the method under test. You can move the call out to the DB connection to another protected method and then in the Test class you create a private class extending the class under test and override the protected method. The DB connection call is now mockable/stubbable etc. Cool!

Stopped watching at 32 mins but need to take notes, especially for the BUILDER type pattern he used for creating Users, it's really nice.

How to Learn, learning techniques

AI stuff