566 Matching Annotations
  1. Last 7 days
    1. find every email on a web page that you're on. The big kahuna - this works for every website. Inject it into a site with Chrome DevTools (more here)

      Use this code below to find every e-mail on a webpage:

      var elems = document.body.getElementsByTagName("*");
      var re = new RegExp("(^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$)");
      for (var i = 0; i < elems.length; i++) {
          if (re.test(elems[i].innerHTML)) {
  2. Aug 2020
    1. “I came to Rust from Haskell, and I feel that Haskell is a very elegant and safe language. The biggest differentiator for me is that there is a greater difference between high-performance code and idiomatic ‘clean’ code in Haskell than in Rust. Most Rust code looks like most other Rust code, even when it performs well. Haskell can become unfamiliar real quick if someone is operating under different libraries and goals from what you are typically doing. Small differences in syntax can result in huge differences in behavior, and Rust has more uniformity on that axis.”
    1. Then when giving answers I'm even less certain. For example I see occasional how-to questions which (IMO) are ridiculously complex in bash, awk, sed, etc. but trivial in python, (<10 lines, no non-standard libraries). On such questions I wait and see if other answers are forthcoming. But if they get no answers, I'm not sure if I should give my 10 lines of python or not.
  3. Jul 2020
    1. Go cheatsheet

      Super useful cheatsheet for the Go programming language.

    1. TLA+ is a high-level language for modeling programs and systems--especially concurrent and distributed ones.

      Need to look more into TLA+ and formal verification with regards to software development.

    1. Essays on programming I think about a lot

      Nice collection of programming essays

    1. Introducing Module#const_source_locationUsing Method#source_location made finding the location of any method fairly easy. Unfortunately, there wasn’t an equivalent for constants. This meant that unless the constant you needed to find was defined in your codebase, finding its source location was not easy.
    2. When FrozenError is raised, it is usually difficult to determine from the context which was the frozen object that a modification was attempted on.Ruby 2.7 introduces FrozenError#receiver which will return the frozen object that modification was attempted on, similar to NameError#receiver. This can help pinpoint exactly what is the frozen object.
    1. dynamic

      A dynamic language (Lisp, Perl, Python, Ruby) is designed to optimize programmer efficiency, so you can implement functionality with less code. A static language (C, C++, etc) is designed to optimize hardware efficiency, so that the code you write executes as quickly as possible. https://stackoverflow.com/questions/20563433/difference-between-static-and-dynamic-programming-languages#:~:text=A%20dynamic%20language%20(Lisp%2C%20Perl,executes%20as%20quickly%20as%20possible.

    2. multi-paradigm

      Programming paradigms are a way to classify programming languages based on their features - these include imperative, declarative,



    1. Most of Algol's "special" characters (⊂, ≡, ␣, ×, ÷, ≤, ≥, ≠, ¬, ⊃, ≡, ∨, ∧, →, ↓, ↑, ⌊, ⌈, ⎩, ⎧, ⊥, ⏨, ¢, ○ and □) can be found on the IBM 2741 keyboard with the APL "golf-ball" print head inserted; these became available in the mid-1960s while ALGOL 68 was being drafted. These characters are also part of the Unicode standard and most of them are available in several popular fonts.
    1. How to Find Programmers For a Startup and a Company

      Learn how to find programmers by reading this article.

  4. Jun 2020
    1. Typical software requirements specify the following
      • All software system inputs
      • All software system outputs
      • All functions that the software system will perform
      • All performance requirements that the software will meet, (e.g., data throughput, reliability, and timing)
      • The definition of all external and user interfaces, as well as any internal software-to-system interfaces
      • How users will interact with the system
      • What constitutes an error and how errors should be handled
      • Required response times
      • The intended operating environment for the software, if this is a design constraint (e.g. hardware platform, operating system)
      • All ranges, limits, defaults, and specific values that the software will accept
      • All safety related requirements, specifications, features, or functions that will be implemented in software
    1. Android is an operating system based on Linux with a Java programming interface for mobile devices such as Smartphone (Touch Screen Devices who supports Android OS) as well for Tablets too.  

      Android is an operating system based on Linux with a Java programming interface for mobile devices such as Smartphone (Touch Screen Devices who supports Android OS) as well for Tablets too.

      To learn more about android visit Android Tutorial

    1. Bootstrap is an open-source HTML, CSS, and JavaScript framework for building responsive and mobile-first applications on the web.

      Bootstrap is an open-source HTML, CSS, and JavaScript framework for building responsive and mobile-first applications on the web. To learn more about bootstrap visit Bootstrap Tutorial

    1. LINQ means Language Integrated Query and it was introduced in .NET Framework 3.5 to query the data from different data sources such as collections, generics, XML Documents, ADO.NET Datasets, SQL, Web Service, etc. in C# and VB.NET. 

      LINQ means Language Integrated Query and it was introduced in .NET Framework 3.5 to query the data from different data sources such as collections, generics, XML Documents, ADO.NET Datasets, SQL, Web Service, etc. in C# and VB.NET. To learn more about LINQ visit LINQ Tutorial

    1. Visual Basic (VB) is an object-oriented programming language and that enables the developers to build a variety of secure and robust applications that run on the .NET Framework.

      Visual Basic (VB) is an object-oriented programming language and that enables the developers to build a variety of secure and robust applications that run on the .NET Framework.

      To learn more about visual basic refer Visual Basic (VB.NET) Tutorial

    1. The brain uses the same area to save coding as it does to save our speech. They found that programming is like talking. The research found out that the brain regions that are most active during coding are those that are also relevant in the processing of natural language.
      • Study shows that programming knowledge is stored in the same area of the brain as speech.
      • Using fMRIs, researchers analysed which parts of the brain are activated during programming.
      • The results essentially show that programming is like talking - the same regions that are active when processing natural language are active during programming.
      • In the study, professional programmers were asked to repeatedly write some code and check other chunks of code for mistakes.
    1. in Python - setting up basic logger is very simple

      Apart from printing the result, it is better to debug with logging.

      Sample logger:

      import logging
          format= '[%(asctime)s] {%(pathname)s:%(lineno)d} %(levelname)s - %(message)s',
      logging.error("Some serious error occurred.")
      logging.warning('Function you are using is deprecated.')

      the sample result:

      [12:52:35] {<stdin>:1} ERROR - Some serious error occurred.
      [12:52:35] {<stdin>:1} WARNING - Function you are using is deprecated.

      to find its location, type:

  5. May 2020
    1. - High-level modules should not depend on low-level modules. Both should depend on the abstraction.- Abstractions should not depend on details. Details should depend on abstractions.


      Dependency Inversion

    2. Clients should not be forced to depend on methods that they do not use.


      Interface Segregation

    3. If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.


      Liskov Substitution

    4. Classes should be open for extension, but closed for modification



    5. A class should have a single responsibility


      Single Responsibility

    1. This tightly controlled build environment is sometimes called a "holy build box". The Traveling Ruby project provides such a holy build box.
    1. Don’t go to code academy, go to design academy. Be advocates of the user & consumer. It’s not about learning how to code, it’s about translating real-world needs to technological specifications in just ways that give end users agency and equity in design, development and delivery. Be a champion of user-centric design. Learn how to steward data and offer your help.

      The importance of learning to design, and interpreting/translating real-world needs.

    1. function (or in the case of type classes, we call these methods)
    2. If you can tell that two types are equal or not equal, that type belongs in the Eq type class.

      two types or rather two things of the same type?

    1. Continuous Delivery of Deployment is about running as thorough checks as you can to catch issues on your code. Completeness of the checks is the most important factor. It is usually measured in terms code coverage or functional coverage of your tests. Catching errors early on prevents broken code to get deployed to any environment and saves the precious time of your test team.

      Continuous Delivery of Deployment (quick summary)

    2. Continuous Integration is a trade off between speed of feedback loop to developers and relevance of the checks your perform (build and test). No code that would impede the team progress should make it to the main branch.

      Continuous Integration (quick summary)

    3. A good CD build: Ensures that as many features as possible are working properly The faster the better, but it is not a matter of speed. A 30-60 minutes build is OK

      Good CD build

    4. A good CI build: Ensures no code that breaks basic stuff and prevents other team members to work is introduced to the main branch Is fast enough to provide feedback to developers within minutes to prevent context switching between tasks

      Good CI build

    5. The idea of Continuous Delivery is to prepare artefacts as close as possible from what you want to run in your environment. These can be jar or war files if you are working with Java, executables if you are working with .NET. These can also be folders of transpiled JS code or even Docker containers, whatever makes deploy shorter (i.e. you have pre built in advance as much as you can).

      Idea of Continuous Delivery

    6. Continuous Delivery is about being able to deploy any version of your code at all times. In practice it means the last or pre last version of your code.

      Continous Delivery

    7. Continuous Integration is not about tools. It is about working in small chunks and integrating your new code to the main branch and pulling frequently.

      Continuous Integration is not about tools

    8. The app should build and start Most critical features should be functional at all times (user signup/login journey and key business features) Common layers of the application that all the developers rely on, should be stable. This means unit tests on those parts.

      Things to be checked by Continous Integration

    9. Continuous Integration is all about preventing the main branch of being broken so your team is not stuck. That’s it. It is not about having all your tests green all the time and the main branch deployable to production at every commit.

      Continuous Integration prevents other team members from wasting time through a pull of faulty code

    1. // ES5-compatible code var myObject = { prop1: 'hello', prop2: 'world', output: function() { console.log(this.prop1 + ' ' + this.prop2); } }; myObject.output(); // hello world

      Creating an object.

    1. Scrum means that “you have to get certain things done with those two weeks.” Kanban means “do what you can do in two weeks.”

      If you get a choice, push for Kanban over Scrum

    2. What people will say is that estimates are for planning – that their purpose is to figure out how long some piece of work is going to take, so that everybody can plan accordingly. In all my five years shipping stuff, I can only recall one project where things really worked that way.

      Project estimations are just energy drainers and stress producers

    3. Be explicit about the difference between hard deadlines

      Different types of deadlines:

      • Hard deadline - something seriously bad to the business will happen if the deadline isn’t met
      • Soft deadline - somebody will look bad if the deadline isn’t met
      • Internal deadline - target internal to the team that will not affect anybody outside of the team
      • Expected completion date - team currently predicts that work will be completed
    4. If you delegate all your IT security to the InfoSec, they will come up with draconian rules

      Try to do some of your own security before delegating everything to InfoSec that will come with draconian restrictions

    5. you should always advocate for having a dedicated SRE if there’s any real risk of after-hours pages that are out of your control.

      Site Reliability Engineers (ideally from different time zones) should've been settled when we might expect after-hours errors

    6. I try to write a unit test any time the expected value of a defect is non-trivial.

      Write unit tests at least for the most important parts of code, but every chunk of code should have a trivial unit test around it – this verifies that the code is written in a testable way, which indeed is extremely important

    7. I’m defining an integration test as a test where you’re calling code that you don’t own

      When to write integration tests:

      • importing code you don't own
      • when you can't trust the code you don't own
    8. Which database technology to choose

      Which database to choose (advice from an Amazon employee):

      • SQL - ad hoc queries and/or support of ACID and transactions
      • NoSQL - otherwise. NoSQL is getting better with transactions and PostgreSQL is getting better with availability, scalability, durability
    9. I would use a serverless function when I have a relatively small and simple chunk of code that needs to run every once in a while.

      When to make a serverless function (advice from an Amazon employee)

    10. Programming languages These will probably expose my ignorance pretty nicely.

      When to use different programming languages (advice from an Amazon employee):

      • Java - enterprise applications
      • C# - Microsoft's spin on Java (useful in the Microsoft's ecosystem)
      • Ruby - when speed is more important then legibility or debugging
      • Python - same as Ruby but also for ML/AI (don't forget to use type hinting to make life a little saner)
      • Go/Rust - fresh web service where latency and performance were more important than community/library support
      • Haskell/Erlang - for very elegant/mathematical functional approach without a lot of business logic
      • Clojure - in situation when you love Lisp (?)
      • Kotlin/Scala - languages compiling to JVM bytecode (preferable over Clojure). Kotlin works with Java and has great IntelliJ support
      • C - classes of applications (operating systems, language design, low-level programming and hardware)
      • C++ - robotics, video games and high frequency trading where the performance gains from no garbage collection make it preferable to Java
      • PHP/Hack - testing server changes without rebuilding. PHP is banned at Amazon due to security reasons, but its successor, Hack, runs a lot of Facebook and Slack's backends
    1. A few takeaways

      Summarising the article:

      • Types and tests save you from stupid mistakes; these're gifts for your future self!
      • Use ESLint and configure it to be your strict, but fair, friend.
      • Think of tests as a permanent console.
      • Types: It is not only about checks. It is also about code readability.
      • Testing with each commit makes fewer surprises when merging Pull Requests.
  6. Apr 2020
    1. I set it with a few clicks at Travis CI, and by creating a .travis.yml file in the repo

      You can set CI with a few clicks using Travis CI and creating a .travis.yml file in your repo:

      language: node_js
      node_js: node
        - npm install -g typescript
        - npm install codecov -g
        - yarn lint
        - yarn build
        - yarn test
        - yarn build-docs
        - codecov
    2. I set it with a few clicks at Travis CI, and by creating a .travis.yml file in the repo

      You can set CI with a few clicks using Travis CI and creating a .travis.yml file in your repo:

      language: node_js
      node_js: node
        - npm install -g typescript
        - npm install codecov -g
        - yarn lint
        - yarn build
        - yarn test
        - yarn build-docs
        - codecov
    3. Continuous integration makes it easy to check against cases when the code: does not work (but someone didn’t test it and pushed haphazardly), does work only locally, as it is based on local installations, does work only locally, as not all files were committed.

      CI - Continuous Integration helps to check the code when it :

      • does not work (but someone didn’t test it and pushed haphazardly),
      • does work only locally, as it is based on local installations,
      • does work only locally, as not all files were committed.
    4. In Python, when trying to do a dubious operation, you get an error pretty soon. In JavaScript… an undefined can fly through a few layers of abstraction, causing an error in a seemingly unrelated piece of code.

      Undefined nature of JavaScript can hide an error for a long time. For example,

      function add(a,b) { return + (a + b) }
      add('2', 2)

      will result in a number, but is it the same one?

    5. With Codecov it is easy to make jest & Travis CI generate one more thing:

      Codecov lets you generate a score on your tests:

    6. I would use ESLint in full strength, tests for some (especially end-to-end, to make sure a commit does not make project crash), and add continuous integration.

      Advantage of tests

    7. It is fine to start adding tests gradually, by adding a few tests to things that are the most difficult (ones you need to keep fingers crossed so they work) or most critical (simple but with many other dependent components).

      Start small by adding tests to the most crucial parts

    8. I found that the overhead to use types in TypeScript is minimal (if any).

      In TypeScript, unlike in JS we need to specify the types:

    9. I need to specify types of input and output. But then I get speedup due to autocompletion, hints, and linting if for any reason I make a mistake.

      In TypeScript, you spend a bit more time in the variable definition, but then autocompletion, hints, and linting will reward you. It also boosts code readability

    10. TSDoc is a way of writing TypeScript comments where they’re linked to a particular function, class or method (like Python docstrings).

      TSDoc <--- TypeScript comment syntax. You can create documentation with TypeDoc

    11. ESLint does automatic code linting

      ESLint <--- pluggable JS linter:

      • mark things that are incorrect,
      • mark things that are unnecessary or risky (e.g. if (x = 5) { ... })
      • set a standard way of writing code
    12. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

      According to the Kernighan's Law, writing code is not as hard as debugging

    13. interactive notebooks fall short when you want to write bigger, maintainable code

      Survey regarding programming notebooks:

    14. Write a new test and the result. If you want to make it REPL-like, instead of writing console.log(x.toString()) use expect(x.toString()).toBe('') and you will directly get the result.

      jest <--- interactive JavaScript (TypeScript and others too) testing framework. You can use it as a VS Code extension.

      Basically, instead of console.log(x.toString()), you can use except(x.toString()).toBe(''). Check this gif to understand it further

    15. I recommend Airbnb style JavaScript style guide and Airbnb TypeScript)

      Recommended style guides from Airbnb for:

    16. Creating meticulous tests before exploring the data is a big mistake, and will result in a well-crafted garbage-in, garbage-out pipeline. We need an environment flexible enough to encourage experiments, especially in the initial place.

      Overzealous nature of TDD may discourage from explorable data science

    1. The programming language is augmented with natural language description details, where convenient, or with compact mathematical notation.
    1. There are many types of CRDTs

      CRDTs have different types, such as Grow-only set and Last-writer-wins register. Check more of them here

    2. Some of our main takeaways:CRDT literature can be relevant even if you're not creating a decentralized systemMultiplayer for a visual editor like ours wasn't as intimidating as we thoughtTaking time to research and prototype in the beginning really paid off

      Key takeaways of developing a live editing tool

    3. traditional approaches that informed ours — OTs and CRDTs

      Traditional approaches of the multiplayer technology

    4. CRDTs refer to a collection of different data structures commonly used in distributed systems. All CRDTs satisfy certain mathematical properties which guarantee eventual consistency. If no more updates are made, eventually everyone accessing the data structure will see the same thing. This constraint is required for correctness; we cannot allow two clients editing the same Figma document to diverge and never converge again

      CRDTs (Conflict-free Replicated Data Types)

    5. They’re a great way of editing long text documents with low memory and performance overhead, but they are very complicated and hard to implement correctly

      Characteristics of OTs

    6. Even if you have a client-server setup, CRDTs are still worth researching because they provide a well-studied, solid foundation to start with

      CRDTs are worth studying for a good foundation

    7. Figma’s multiplayer servers keep track of the latest value that any client has sent for a given property on a given object

      No conflict:

      • two clients changing unrelated properties on the same object
      • two clients changing the same property on unrelated objects.


      • two clients changing the same property on the same object (document will end up with the last value sent)
    8. Figma doesn’t store any properties of deleted objects on the server. That data is instead stored in the undo buffer of the client that performed the delete. If that client wants to undo the delete, then it’s also responsible for restoring all properties of the deleted objects. This helps keep long-lived documents from continuing to grow in size as they are edited

      Undo option

    9. it's important to be able to iterate quickly and experiment before committing to an approach. That's why we first created a prototype environment to test our ideas instead of working in the real codebase

      First work with a prototype, then the real codebase

    10. Designers worried that live collaborative editing would result in “hovering art directors” and “design by committee” catastrophes.

      Worries of using a live collaborative editing

    11. We had a lot of trouble until we settled on a principle to help guide us: if you undo a lot, copy something, and redo back to the present (a common operation), the document should not change. This may seem obvious but the single-player implementation of redo means “put back what I did” which may end up overwriting what other people did next if you’re not careful. This is why in Figma an undo operation modifies redo history at the time of the undo, and likewise a redo operation modifies undo history at the time of the redo

      Undo/Redo working

    12. operational transforms (a.k.a. OTs), the standard multiplayer algorithm popularized by apps like Google Docs. As a startup we value the ability to ship features quickly, and OTs were unnecessarily complex for our problem space

      Operational Transforms (OT) are unnecessarily complex for problems unlike Google Docs

    13. Every Figma document is a tree of objects, similar to the HTML DOM. There is a single root object that represents the entire document. Underneath the root object are page objects, and underneath each page object is a hierarchy of objects representing the contents of the page. This tree is is presented in the layers panel on the left-hand side of the Figma editor.

      Structure of Figma documents

    14. When a document is opened, the client starts by downloading a copy of the file. From that point on, updates to that document in both directions are synced over the WebSocket connection. Figma lets you go offline for an arbitrary amount of time and continue editing. When you come back online, the client downloads a fresh copy of the document, reapplies any offline edits on top of this latest state, and then continues syncing updates over a new WebSocket connection

      Offline editing isn't a problem, unlike the online one

    15. An important consequence of this is that changes are atomic at the property value boundary. The eventually consistent value for a given property is always a value sent by one of the clients. This is why simultaneous editing of the same text value doesn’t work in Figma. If the text value is B and someone changes it to AB at the same time as someone else changes it to BC, the end result will be either AB or BC but never ABC

      Consequence of approaches like last-writer-wins

    16. We use a client/server architecture where Figma clients are web pages that talk with a cluster of servers over WebSockets. Our servers currently spin up a separate process for each multiplayer document which everyone editing that document connects to

      Way Figma approaches client/server architecture

    17. CRDTs are designed for decentralized systems where there is no single central authority to decide what the final state should be. There is some unavoidable performance and memory overhead with doing this. Since Figma is centralized (our server is the central authority), we can simplify our system by removing this extra overhead and benefit from a faster and leaner implementation

      CRDTs are designed for decentralized systems

    1. Sometimes it's interesting to explain some code (How many time you spend trying to figure out a regex pattern when you see one?), but, in 99% of the time, comments could be avoided.

      Generally try to avoid (avoid != forbid) comments.


      1. Become outdated, confusing your future self (Yesterday I lost some precious time because of an outdated comment)
      2. Could be replaced for some better named variable/function/class.
      3. They pollute the code unnecessarily.
    2. When we talk about abstraction levels, we can classify the code in 3 levels: high: getAdress medium: inactiveUsers = Users.findInactives low: .split(" ")

      3 abstraction levels:

      1. high: getAdress
      2. medium: inactiveUsers = Users.findInactives
      3. low: .split(" ")


      • The high level abstraction are functions that you create, like searchForsomething()
      • The medium level are methods in your object, like account.unverifyAccount
      • The low level are methods that the language provides, like map, to_downncase and so on
    3. The ideal is not to mix the abstraction levels in only one function.

      Try not mixing abstraction levels inside a single function

    4. There is another maxim also that says: you must write the same code a maximum of 3 times. The third time you should consider refactoring and reducing duplication

      Avoid repeating the same code over and over

    5. Should be nouns, and not verbs, because classes represent concrete objects

      Class names = nouns

    6. Uncle Bob, in clean code, defends that the best order to write code is: Write unit tests. Create code that works. Refactor to clean the code.

      Best order to write code (according to Uncle Bob):

      1. Write unit tests.
      2. Create code that works.
      3. Refactor to clean the code.
    7. int d could be int days

      When naming things, focus on giving meaningful names, that you can pronounce and are searchable. Also, avoid prefixes

    8. naming things, write better functions and a little about comments. Next, I intend to talk about formatting, objects and data structures, how to handle with errors, about boundaries (how to deal with another's one code), unit testing and how to organize your class better. I know that it'll be missing an important topic about code smells

      Ideas to consider while developing clean code:

      • naming things
      • better functions
      • comments
      • formatting
      • objects and data structures
      • handling error
      • boundaries (handling another's one code)
      • unit testing
      • organising classes
      • code smells
    9. Should be verbs, and not nouns, because methods represent actions that objects must do

      Methods names = verbs

    10. decrease the switch/if/else is to use polymorphism

      It's better to avoid excessive switch/if/else statements


    11. In the ideal world, they should be 1 or 2 levels of indentation

      Functions in the ideal world shouldn't be long

    1. "The Big Picture" is one of those things that people say a whole lot but can mean so many different things. Going through all of these articles, they tend to mean any (or all) of these things

      Thinking about The Big Picture:

      1. The Business Stuff - how to meet KPIs or the current big deadline or whatever.
      2. The User Stuff - how to actually provide value to the people who use what you make.
      3. The Technology Stuff - how to build something that will last a long time.
    2. Considering that there are still a ton of COBOL jobs out there, there is no particular technology that you need to know

      RIght, there is no specific need to learn that one technology

    3. read Knuth, or Pragmatic Programming, or Clean Code, or some other popular book

      Classic programming related books

    4. Senior developers are more cautious, thoughtful, pragmatic, practical and simple in their approaches to solving problems.

      Interesting definition of senior devs

    1. In recent years we’ve also begun to see increasing interest in exploratory testing as an important part of the agile toolbox

      Waterfall software development ---> agile ---> exploratory testing

    2. When I began coding, around 30 years ago, waterfall software development was used nearly exclusively.
    3. Mathematica didn’t really help me build anything useful, because I couldn’t distribute my code or applications to colleagues (unless they spent thousands of dollars for a Mathematica license to use it), and I couldn’t easily create web applications for people to access from the browser. In addition, I found my Mathematica code would often end up much slower and more memory hungry than code I wrote in other languages.

      Disadvantages of Mathematica:

      • memory hungry, slow code
      • expensive code
      • non-distributable license
    4. In the 1990s, however, things started to change. Agile development became popular. People started to understand the reality that most software development is an iterative process
    5. a methodology that combines a programming language with a documentation language, thereby making programs more robust, more portable, more easily maintained, and arguably more fun to write than programs that are written only in a high-level language. The main idea is to treat a program as a piece of literature, addressed to human beings rather than to a computer.

      Exploratory testing described by Donald Knuth

    6. Development Pros Cons

      Table comparing pros and cons of:

      • IDE/Editor
      • REPL/shell
      • Traditional notebooks (like Jupyter)
    7. This kind of “exploring” is easiest when you develop on the prompt (or REPL), or using a notebook-oriented development system like Jupyter Notebooks

      It's easier to explore the code:

      • when you develop on the prompt (or REPL)
      • in notebook-oriented system like Jupyter

      but, it's not efficient to develop in them

    8. notebook contains an actual running Python interpreter instance that you’re fully in control of. So Jupyter can provide auto-completions, parameter lists, and context-sensitive documentation based on the actual state of your code

      Notebook makes it easier to handle dynamic Python features

    9. They switch to get features like good doc lookup, good syntax highlighting, integration with unit tests, and (critically!) the ability to produce final, distributable source code files, as opposed to notebooks or REPL histories

      Things missed in Jupyter Notebooks:

      • good doc lookup
      • good syntax highlighting
      • integration with unit tests
      • ability to produce final, distributable source code files
    10. Exploratory programming is based on the observation that most of us spend most of our time as coders exploring and experimenting

      In exploratory programming, we:

      • experiment with a new API to understand how it works
      • explore the behavior of an algorithm that we're developing
      • debug our code through combination of inputs
    1. Developing in the cloud

      Well paid cloud platforms:

    2. Finding a database management system that works for you

      Well paid database technologies:

    3. Here are a few very prominent technologies that you can look into and what impact each one might have on your salary

      Other well paid frameworks, libraries and tools:

    4. What programming language should I learn next?

      Most paid programming languages:

    5. Android and iOS

      Payment for mobile OS:

    6. Frontend Devs: What should I learn after JavaScript? Explore these frameworks and libraries

      Most paid JS frameworks and libraries:

    1. First, you’ve spread the logic across a variety of different systems, so it becomes more difficult to reason about the application as a whole. Second, more importantly, the logic has been implemented as configuration as opposed to code. The logic is constrained by the ability of the applications which have been wired together, but it’s still there.

      Why "no code" trend is dangerous in some way (on the example of Zapier):

      1. You spread the logic across multiple systems.
      2. Logic is maintained in configuration rather than code.
    2. the developer doesn’t need to worry about allocating memory, or the character set encoding of the string, or a host of other things.

      Comparison of C (1972) and TypeScript (2012) code.

      (check the code above)

    3. “No Code” systems are extremely good for putting together proofs-of-concept which can demonstrate the value of moving forward with development.

      Great point of "no code" trend

    4. With someone else’s platform, you often end up needing to construct elaborate work-arounds for missing functionality, or indeed cannot implement a required feature at all.

      You can quickly implement 80% of the solution in Salesforce using a mix of visual programming (basic rule setting and configuration), but later it's not so straightforward to add the missing 20%

    1. Summary

      In doing a code review, you should make sure that:

      • The code is well-designed.
      • The functionality is good for the users of the code.
      • Any UI changes are sensible and look good.
      • Any parallel programming is done safely.
      • The code isn’t more complex than it needs to be.
      • The developer isn’t implementing things they might need in the future but don’t know they need now.
      • Code has appropriate unit tests.
      • Tests are well-designed.
      • The developer used clear names for everything.
      • Comments are clear and useful, and mostly explain why instead of what.
      • Code is appropriately documented (generally in g3doc).
      • The code conforms to our style guides.
    1. "Continuous Delivery is the ability to get changes of all types — including new features, configuration changes, bug fixes, and experiments — into production, or into the hands of users, safely and quickly in a sustainable way". -- Jez Humble and Dave Farley

      Continuous Delivery

    2. Another approach is to use a tool like H2O to export the model as a POJO in a JAR Java library, which you can then add as a dependency in your application. The benefit of this approach is that you can train the models in a language familiar to Data Scientists, such as Python or R, and export the model as a compiled binary that runs in a different target environment (JVM), which can be faster at inference time

      H2O - export models trained in Python/R as a POJO in JAR

    3. Continuous Delivery for Machine Learning (CD4ML) is a software engineering approach in which a cross-functional team produces machine learning applications based on code, data, and models in small and safe increments that can be reproduced and reliably released at any time, in short adaptation cycles.

      Continuous Delivery for Machine Learning (CD4ML) (long definition)

      Basic principles:

      • software engineering approach
      • cross-functional team
      • producing software based on code, data, and ml models
      • small and safe increments
      • reproducible and reliable software release
      • short adaptation cycles
    4. In order to formalise the model training process in code, we used an open source tool called DVC (Data Science Version Control). It provides similar semantics to Git, but also solves a few ML-specific problems:

      DVC - transform model training process into code.


      • it has multiple backend plugins to fetch and store large files on an external storage outside of the source control repository;
      • it can keep track of those files' versions, allowing us to retrain our models when the data changes;
      • it keeps track of the dependency graph and commands used to execute the ML pipeline, allowing the process to be reproduced in other environments;
      • it can integrate with Git branches to allow multiple experiments to co-exist
    5. Machine Learning pipeline for our Sales Forecasting problem, and the 3 steps to automate it with DVC

      Sales Forecasting process Sales Forecasting process

    6. Continuous Delivery for Machine Learning end-to-end process

      end-to-end process

    7. common functional silos in large organizations can create barriers, stifling the ability to automate the end-to-end process of deploying ML applications to production

      Common ML process (leading to delays and frictions) ML process

    8. There are different types of testing that can be introduced in the ML workflow.

      Automated tests for ML system:

      • validating data
      • validating component integration
      • validating the model quality
      • validating model bias and fairness
    9. example of how to combine different test pyramids for data, model, and code in CD4ML

      Combining tests for data (purple), model (green) and code (blue) testing

    10. A deployment pipeline automates the process for getting software from version control into production, including all the stages, approvals, testing, and deployment to different environments

      Deployment pipeline

    11. We chose to use GoCD as our Continuous Delivery tool, as it was built with the concept of pipelines as a first-class concern

      GoCD - open source Continuous Delivery tool

    12. Continuous Delivery for Machine Learning (CD4ML) is the discipline of bringing Continuous Delivery principles and practices to Machine Learning applications.

      Continuous Delivery for Machine Learning (CD4ML)

    1. Sometimes, the best way to learn is to mimic others. Here are some great examples of projects that use documentation well:

      Examples of projects that use documentation well

      (chech the list below)

    2. “Code is more often read than written.” — Guido van Rossum
    3. Documenting code is describing its use and functionality to your users. While it may be helpful in the development process, the main intended audience is the users.

      Documenting code:

      • describing use to your users (main audience)
    4. Class method docstrings should contain the following: A brief description of what the method is and what it’s used for Any arguments (both required and optional) that are passed including keyword arguments Label any arguments that are considered optional or have a default value Any side effects that occur when executing the method Any exceptions that are raised Any restrictions on when the method can be called

      Class method should contain:

      • brief description
      • arguments
      • label on default/optional arguments
      • side effects description
      • raised exceptions
      • restrictions on when the method can be called

      (check example below)

    5. Comments to your code should be kept brief and focused. Avoid using long comments when possible. Additionally, you should use the following four essential rules as suggested by Jeff Atwood:

      Comments should be as concise as possible. Moreover, you should follow 4 rules of Jeff Atwood:

      1. Keep comments close to the code being described.
      2. Don't use complex formatting (such as tables).
      3. Don't comment obvious things.
      4. Design code in a way it comments itself.
    6. From examining the type hinting, you can immediately tell that the function expects the input name to be of a type str, or string. You can also tell that the expected output of the function will be of a type str, or string, as well.

      Type hinting introduced in Python 3.5 extends 4 rules of Jeff Atwood and comments the code itself, such as this example:

      def hello_name(name: str) -> str:
          return(f"Hello {name}")
      • user knows that the code expects input of type str
      • the same about output
    7. Docstrings can be further broken up into three major categories: Class Docstrings: Class and class methods Package and Module Docstrings: Package, modules, and functions Script Docstrings: Script and functions

      3 main categories of docstrings

    8. According to PEP 8, comments should have a maximum length of 72 characters.

      If comment_size > 72 characters:

      use `multiple line comment`
    9. Docstring conventions are described within PEP 257. Their purpose is to provide your users with a brief overview of the object.

      Docstring conventions

    10. All multi-lined docstrings have the following parts: A one-line summary line A blank line proceeding the summary Any further elaboration for the docstring Another blank line

      Multi-line docstring example:

      """This is the summary line
      This is the further elaboration of the docstring. Within this section,
      you can elaborate further on details as appropriate for the situation.
      Notice that the summary and the elaboration is separated by a blank new
      # Notice the blank line above. Code should continue on this line.
    11. say_hello.__doc__ = "A simple function that says hello... Richie style"

      Example of using __doc:

      Code (version 1):

      def say_hello(name):
          print(f"Hello {name}, is it me you're looking for?")
      say_hello.__doc__ = "A simple function that says hello... Richie style"

      Code (alternative version):

      def say_hello(name):
          """A simple function that says hello... Richie style"""
          print(f"Hello {name}, is it me you're looking for?")


      >>> help(say_hello)


      Help on function say_hello in module __main__:
          A simple function that says hello... Richie style
    12. class constructor parameters should be documented within the __init__ class method docstring


    13. Scripts are considered to be single file executables run from the console. Docstrings for scripts are placed at the top of the file and should be documented well enough for users to be able to have a sufficient understanding of how to use the script.

      Docstrings in scripts

    14. Documenting your code, especially large projects, can be daunting. Thankfully there are some tools out and references to get you started

      You can always facilitate documentation with tools.

      (check the table below)

    15. Commenting your code serves multiple purposes

      Multiple purposes of commenting:

      • planning and reviewing code - setting up a code template
      • code description
      • algorithmic description - for example, explaining the work of an algorithm or the reason of its choice
      • tagging - BUG, FIXME, TODO
    16. In general, commenting is describing your code to/for developers. The intended main audience is the maintainers and developers of the Python code. In conjunction with well-written code, comments help to guide the reader to better understand your code and its purpose and design

      Commenting code:

      • describing code to/for developers
      • help to guide the reader to better understand your code, its purpose/design
    17. Along with these tools, there are some additional tutorials, videos, and articles that can be useful when you are documenting your project

      Recommended videos to start documenting

      (check the list below)

    18. If you use argparse, then you can omit parameter-specific documentation, assuming it’s correctly been documented within the help parameter of the argparser.parser.add_argument function. It is recommended to use the __doc__ for the description parameter within argparse.ArgumentParser’s constructor.


    19. There are specific docstrings formats that can be used to help docstring parsers and users have a familiar and known format.

      Different docstring formats:

    20. Daniele Procida gave a wonderful PyCon 2017 talk and subsequent blog post about documenting Python projects. He mentions that all projects should have the following four major sections to help you focus your work:

      Public and Open Source Python projects should have the docs folder, and inside of it:

      • Tutorials
      • How-To Guides
      • References
      • Explanations

      (check the table below for a summary)

    21. Since everything in Python is an object, you can examine the directory of the object using the dir() command

      dir() function examines directory of Python objects. For example dir(str).

      Inside dir(str) you can find interesting property __doc__

    22. Documenting your Python code is all centered on docstrings. These are built-in strings that, when configured correctly, can help your users and yourself with your project’s documentation.

      Docstrings - built-in strings that help with documentation

    23. Along with docstrings, Python also has the built-in function help() that prints out the objects docstring to the console.

      help() function.

      After typing help(str) it will return all the info about str object

    24. The general layout of the project and its documentation should be as follows:
      ├── project/  # Project source code
      ├── docs/
      ├── README
      ├── examples.py

      (private, shared or open sourced)

    25. In all cases, the docstrings should use the triple-double quote (""") string format.

      Think only about """ when using docstrings

    1. Each format makes tradeoffs in encoding, flexibility, and expressiveness to best suit a specific use case.

      Each data format brings different tradeoffs:

      • A format optimized for size will use a binary encoding that won’t be human-readable.
      • A format optimized for extensibility will take longer to decode than a format designed for a narrow use case.
      • A format designed for flat data (like CSV) will struggle to represent nested data.
    1. Computers can only natively store integers, so they need some way of representing decimal numbers. This representation comes with some degree of inaccuracy. That's why, more often than not, .1 + .2 != .3

      Computers make up their way to store decimal numbers

    1. Cross-platform development is now a standard because of wide variety of architectures like mobile devices, cloud servers, embedded IoT systems. It was almost exclusively PCs 20 years ago.
    2. A package management ecosystem is essential for programming languages now. People simply don’t want to go through the hassle of finding, downloading and installing libraries anymore. 20 years ago we used to visit web sites, downloaded zip files, copied them to correct locations, added them to the paths in the build configuration and prayed that they worked.

      How library management changed in 20 years

    3. IDEs and the programming languages are getting more and more distant from each other. 20 years ago an IDE was specifically developed for a single language, like Eclipse for Java, Visual Basic, Delphi for Pascal etc. Now, we have text editors like VS Code that can support any programming language with IDE like features.

      How IDEs "unified" in comparison to the last 20 years

    4. Your project has no business value today unless it includes blockchain and AI, although a centralized and rule-based version would be much faster and more efficient.

      Comparing current project needs to those 20 years ago

    5. Being a software development team now involves all team members performing a mysterious ritual of standing up together for 15 minutes in the morning and drawing occult symbols with post-its.

      In comparison to 20 years ago ;)

    6. Language tooling is richer today. A programming language was usually a compiler and perhaps a debugger. Today, they usually come with the linter, source code formatter, template creators, self-update ability and a list of arguments that you can use in a debate against the competing language.

      How coding became much more supported in comparison to the last 20 years

    7. There is StackOverflow which simply didn’t exist back then. Asking a programming question involved talking to your colleagues.

      20 years ago StackOverflow wouldn't give you a hand

    8. Since we have much faster CPUs now, numerical calculations are done in Python which is much slower than Fortran. So numerical calculations basically take the same amount of time as they did 20 years ago.

      Python vs Fortran ;)

    1. I am not sure how but one kind soul somehow found the project, forked it, refactored it, "modernized" it, added linting, code sniffing, added CI and opened the pull request.

      It's worth sharing your code, since someone can always find it and improve it, so that you can learn from it

    2. It is solved when you understand why it occurred and why it no longer does.

      What does it mean for a problem to be solved?

    1. Let's reason through our memoizer before we write any code.

      Operations performed by a memoizer:

      • Takes a reference to a function as an input
      • Returns a function (so it can be used as it normally would be)
      • Creates a cache of some sort to hold the results of previous function calls
      • Any future time calling the function, returns a cached result if it exists
      • If the cached value doesn't exist, calls the function and store that result in the cache

      Which is written as:

      // Takes a reference to a function
      const memoize = func => {
        // Creates a cache of results
        const results = {};
        // Returns a function
        return (...args) => {
          // Create a key for results cache
          const argsKey = JSON.stringify(args);
          // Only execute func if no cached value
          if (!results[argsKey]) {
            // Store function call result in cache
            results[argsKey] = func(...args);
          // Return cached value
          return results[argsKey];
    2. Let's replicate our inefficientSquare example, but this time we'll use our memoizer to cache results.

      Replication of a function with the use of memoizer (check the code below this annotation)

    3. The biggest problem with JSON.stringify is that it doesn't serialize certain inputs, like functions and Symbols (and anything you wouldn't find in JSON).

      Problem with JSON.stringify.

      This is why the previous code shouldn't be used in production

    4. Memoization is an optimization technique used in many programming languages to reduce the number of redundant, expensive function calls. This is done by caching the return value of a function based on its inputs.

      Memoization (simple definition)

    1. The best way to explain the difference between launch and attach is to think of a launch configuration as a recipe for how to start your app in debug mode before VS Code attaches to it, while an attach configuration is a recipe for how to connect VS Code's debugger to an app or process that's already running.

      Simple difference between two core debugging modes: Launch and Attach available in VS Code.

      Depending on the request (attach or launch), different attributes are required, and VS Code's launch.json validation and suggestions should help with that.

    2. Logpoint is a variant of a breakpoint that does not "break" into the debugger but instead logs a message to the console. Logpoints are especially useful for injecting logging while debugging production servers that cannot be paused or stopped. A Logpoint is represented by a "diamond" shaped icon. Log messages are plain text but can include expressions to be evaluated within curly braces ('{}').

      Logpoints - log messages to the console when breakpoint is hit.

      Can include expressions to be evaluated with {}, e.g.:

      fib({num}): {result}


    3. Here are some optional attributes available to all launch configurations

      Optional arguments for launch.json:

      • presentation ("order", "group" or "hidden")
      • preLaunchTask
      • postDebugTask
      • internalConsoleOptions
      • debugServer
      • serverReadyAction
    1. Version control is at the heart of any modern engineering org. The ability for multiple engineers to asynchronously contribute to a codebase is crucial—and with notebooks, it’s very hard.

      Version control in notebooks?

    2. The priorities in building a production machine learning pipeline—the series of steps that take you from raw data to product—are not fundamentally different from those of general software engineering.
      1. Your pipeline should be reproducible
      2. Collaborating on your pipeline should be easy
      3. All code in your pipeline should be testable
    3. Reproducibility is an issue with notebooks. Because of the hidden state and the potential for arbitrary execution order, generating a result in a notebook isn’t always as simple as clicking “Run All.”

      Problem of reproducibility in notebooks

    4. A notebook, at a very basic level, is just a bunch of JSON that references blocks of code and the order in which they should be executed.But notebooks prioritize presentation and interactivity at the expense of reproducibility. YAML is the other side of that coin, ignoring presentation in favor of simplicity and reproducibility—making it much better for production.

      Summary of the article:

      Notebook = presentation + interactivity

      YAML = simplicity + reproducibility

    1. Use camelCase when naming objects, functions, and instances.

      camelCase for objects, functions and instances

      const thisIsMyFuction() {}
    2. Use PascalCase only when naming constructors or classes.

      PascalCase for constructors and classes

      // good
      class User {
        constructor(options) {
          this.name = options.name;
      const good = new User({
        name: 'yup',