Tag: notes

Generative AI for Everyone | Notes | Week 1

January 13th, 2024
Recently I finished the Andrew Ng’s course on Coursera – Generative AI for Everyone. These are my notes for week 1 from that course.

Generative AI is defined as artificial intelligence systems that can generate high quality content like images, text, audio and video. Through chatGPT, we have seen it can produce text. Adobe has AI in it’s tool, using which we can create images using prompts.

Andrew makes a point in one of the videos that AI technology is general purpose. Just like electricity is used to power many things, AI can be applied to various problems. We already see use of AI applications in day to day lives like spam prediction, recommendations on Amazon/netflix, chatGPT, etc.

Some applications for generative ai –
1. Writing – As LLMs work by predicting next words and sentences, it can be used to write something for you. Example, you can ask LLMs to write your linkedin post/blog post for you. LLMs are also used for translating from one language to another.
2. Reading – LLMs can also read long texts and create smaller inference from it. For example, you can ask LLM to go through your resume and create a linkedin summary for you.
3. Chatting – LLMs can be build to use specialized chatbots for an organization as per the requirements.
Limitations of LLMs –
1. Knowledge cutoff – LLM’s knowledge is confined to the data it was used to train it’s model.
2. Hallucinations – LLMs can make stuff in very confident and authoritative.
3. Input length (prompt length/context length) and output is limited.
4. It doesn’t work well with tabular (structured) data.
5. LLMs can reflect the bias of the data it was trained on.
Thanks for stopping by!
Clean Architecture – Chapter 1

March 8th, 2021

What is design? What is architecture? This chapter is based on these two questions. According to the author, both are the same. One cannot be present in place of the other.

To illustrate their sameness, he uses the example of an architect who designs a home. The architecture of the home not only contains the overall layout of rooms and floors (software architecture – high level) but also the minute details like places for sockets, doors, pipes, etc. (software design – low level).

The goal of software architecture is to minimize the human resources that are needed to build and maintain the required system.
– Robert Marti, Clean Architecture

When is a design good – If the effort needed to build a system is low and stays low throughout the development and maintenance, then only the design is good.

The author gives example from a real company, whose initial development costs were low, but they became super high over the years. On further analysis, one could see number of lines of code not increasing, but cost per line of code increasing as number of developers increased over the years.

Through his example, he wants to show the consequences of bad design. He explains that in the rush to deliver to market quickly, the developers do not take time to design right before coding, resulting in a system that gets complicated with the addition of new features over time, becoming more and more expensive. Thus spending more time on the development of new features later. Instead, if they had taken time to design right before starting the implementation, they would have spent more time in the beginning, but the overall same amount of time if we combine the time spent on new features later.

Thanks for stopping by.
Clean Code Notes – Formatting

January 12th, 2021
Notes from the book Clean Code
- Vertical Formatting – Files should be 200 lines to 500 lines long. Smaller files are easier to read than the longer ones.
- Have spaces between different sections of code, improves readability.
- The vertical distance between closely related concepts should be less.
- Caller function should be above callee function and vertical distance between both should be minimum.
- Horizontal Formatting – length of each line should be small, proper indentation, spaces at right places.
Clean Code Notes – Comments

January 6th, 2021
Notes from the book Clean Code
- When comments are good –
  - legal comments
  - providing information eg – information about an abstract method.
  - explaining intent
  - clarifying some obscure argument or return value.
  - add warnings
  - for TODOs
  - java docs
- When comments are bad –
  - any comment that makes you look at other parts of code to understand it’s meaning.
  - redundant comments, not required as the code itself is explanatory, might even confuse/mislead the reader. Unnecessary comments even obscure and reduce readability, eg, too many Javadoc comments.
  - journal comments
  - Javadoc comments before every method and variable are too much. Javadocs in nonpublic methods
  - Misleading comments
  - Position markers
  - the comment that could have been code.
  - Function headers
  - comments with too much information
Clean Code Notes – Functions

January 5th, 2021
Notes from the book Clean Code.
- Functions should be small. They should max 20 lines long. An ideal function should be just 2-5 lines solving only one purpose.
- The if/while/loop blocks should be one line long, which means they should enclose another function call.
- A function should do only one thing. One level of abstraction per function. If a function does only those steps that decompose the name of the function, it is doing only one thing and it is at one level of abstraction.
- The Stepdown Rule – Every function should be followed by another function which is the next level of abstraction. One should be able to read the functions top-down like reading a narrative.
- The Switch Statement –
  - cannot be reduced in size.
  - violates the Single Responsibility Principle as there is more than one reason for it to change.
  - moreover, it can grow with the addition of new conditions.
  - A Solution is to bury the switch statement in the basement Abstract Factory and let no one see it. The factory will then use the switch statement to create appropriate instances of the derivatives of the object. [ Abstract Factory is a creational design pattern that lets you produce families of related objects without specifying their concrete classes. ]
- Use descriptive names. Don’t be shy of using long names.
- Be consistent in names, use similar phrases, nouns, and verbs.
- Try to limit arguments. Best is no argument, next best is one argument. Multiple arguments make reading functions difficult as well as testing them.
- Monadic functions ( functions with one argument) should always return something.
- Diads and Triads functions are difficult to read and grasp and should be avoided whenever possible.
- Multiple arguments can be clubbed into objects, which can reduce arguments.
- Have function names with verbs(intent) and keywords. eg assertEquals can be changed to assertExpectedEqualsActual, which can help remove the need to remember the ordering of arguments.
- Avoid output arguments, if the function changes the state of something then let it change the state of its owning object.
- Return exceptions instead of returning error codes.
  - With exceptions, one can separate the error path from the happy path
  - With error codes, there is usually a file maintaining that error codes, which can change any time, making the dependencies to change as well. With exceptions, we can avoid this.
- The code inside try-catch blocks should be moved to separate functions of their own.
- Dijkstra’s rule of structured programming – every function should have exactly one entry and one exit, ie no break/continue/goto, and a single return statement. With small functions, we can have multiple return statements and break/continue.

Tag: notes

Generative AI for Everyone | Notes | Week 1

Clean Architecture – Chapter 1

Clean Code Notes – Formatting

Clean Code Notes – Comments

Clean Code Notes – Functions