LangChain: The oldest and most comprehensive framework, offering extensive integrations but often criticized for its steep learning curve and boilerplate code.
LlamaIndex: Primarily focused on data-intensive applications, excelling at connecting language models to external data sources through advanced retrieval and indexing.
AutoGen (Microsoft): A multi-agent framework that shines at creating conversational agents that can collaborate and delegate tasks to solve complex problems.
CrewAI: Designed for orchestrating role-playing autonomous agents, making it easy to define agents with specific jobs and have them work together in a structured crew.
AgentVerse: A versatile framework that provides a “lego-like” approach to building and composing customized multi-agent environments for various applications.
ChatDev: A “virtual software company” framework where different agents (CEO, programmer, tester) simulate a software development lifecycle to complete coding tasks.
SuperAGI: A developer-centric framework focused on building autonomous agents with useful features like provisioning, deployment, and a graphical user interface.
AI Droid (by Vicuna): A lightweight and fast framework designed for mobile and edge devices, prioritizing efficiency and low-resource consumption.
GPTeam: Similar to ChatDev, this framework uses role-playing agents (like product managers and engineers) to collaboratively work on development tasks from a single prompt.
Agenta: An open-source platform that helps developers evaluate, test, and deploy language model applications with features for prompt management and A/B testing.
OpenAI Assistants API: OpenAI’s native solution for building stateful, assistant-like agents directly on their platform, handling conversation history and tool integration internally.
LangGraph: Built on LangChain, this framework is specifically for creating cyclical, stateful multi-agent workflows, treating agent interactions as steps in a graph.
Alpine.js : Alpine is a rugged, minimal tool for composing behavior directly in your markup. Think of it like jQuery for the modern web. Plop in a script tag and get going.
Something in between a Product Manager and a Software Engineer : Product Engineer i.e. PMs are sometimes not enough technical and SWEs are sometimes not enough product oriented https://refactoring.fm/p/how-to-become-a-product-engineer
Meta, for instance, trained its new Llama 3 models with about 10 times more data and 100 times more compute than Llama 2. Amid a chip shortage, it used two 24,000 GPU clusters, with each chip running around the price of a luxury car. It employed so much data in its AI work, it considered buying the publishing house Simon & Schuster to find more.
Redis forks (after the licence change) : – redict : https://redict.io/ Drew DeVault + others? – valkey : https://valkey.io/ backed by AWS, Google, Oracle, Ericsson, and Snap, with the Linux Foundation; more to come imo.
golang fasthttp (replacement for standard net/http if you need “to handle thousands of small to medium requests per second and needs a consistent low millisecond response time”. “Currently fasthttp is successfully used by VertaMedia in a production serving up to 200K rps from more than 1.5M concurrent keep-alive connections per physical server.” https://github.com/valyala/fasthttp
I find truly interesting the point around promoting a write culture (Execs/Directors in tech blog, SWEs on tech blogs/internal technical documents) : https://newsletter.pragmaticengineer.com/i/140970283/writing-culture I’m a long-time believer that writing clarifies thinking more than talking and writing persists information, makes it searchable, talking does not. “Verba volant, scripta manent” as the Latins use to say. But this idea shifted into “just enough” documentation (which means it is not necessary) in SW engineering latest methodologies so it is interesting that a multi billion company like stripe is going totally against the tide.
(or the Attraction for Complexity) There is a very common tendency in computer science and it is to complicate solutions. This complication is often referred as incidental/accidental complexity i.e. anything we coders/designers do to make more complex a simple matter. Some times this is called over engineering and stems from the best intentions :
Attraction to Complexity: there’s often a misconception that more complex solutions are inherently better or more sophisticated. This can lead to choosing complicated approaches over simpler, more effective ones.
Technological Enthusiasm: developers might be eager to try out new technologies, patterns, or architectures. While innovation is important, using new tech for its own sake can lead to unnecessary complexity.
Anticipating Future Needs: developers may try to build solutions that are overly flexible to accommodate potential future requirements. This often leads to complex designs that are not needed for the current scope of the project.
Lack of Experience or Misjudgment: less experienced developers might not yet have the insight to choose the simplest effective solution, while even seasoned developers can sometimes overestimate what’s necessary for a project.
Avoiding Refactoring: In an attempt to avoid refactoring in the future, developers might add layers of abstraction or additional features they think might be needed later, resulting in over-engineered solutions.
Miscommunication or Lack of Clear Requirements: without clear requirements or effective communication within a team, developers might make assumptions about what’s needed, leading to solutions that are more complex than necessary.
Premature Optimization: trying to optimize every aspect of a solution from the beginning can lead to complexity. The adage “premature optimization is the root of all evil” highlights the pitfalls of optimizing before it’s clear that performance is an issue.
Unclear Problem Definition: not fully understanding the problem that needs to be solved can result in solutions that are more complicated than needed. A clear problem definition is essential for a simple and effective solution.
Personal Preference or Style: sometimes, the preference for certain coding styles, architectures, or patterns can lead to more complex solutions, even if simpler alternatives would suffice.
Fear of Under-Engineering: there can be a fear of delivering a solution that appears under-engineered or too simplistic, leading to adding unnecessary features or layers of abstraction.
You’ve probably seen these acronyms around : SSG, SSR, MPA, SPA, PWA. Web design is getting complex and this tries to explain (with the help of other good content) what these acronyms mean :
PWA : Progressive Web App, web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features. Not sure if this is a web design pattern
MPA : Multi Page Application, every operation requests data from server, receives a new page (html+css+js) and renders the data in the browser.
SPA : Single Page Application, performs inside a browser and does not require page reloading during its use. Initial html+cs+js is obtained from the server and then all login is done in js browser side.More info here and here
CSR : Client Side Rendering, all rendering happens in the browser. Use when UI is complex, lots of dynamic data, you need auth and SEO contents are not that many.
SSR : Server Side Rendering, as the acronyms imply, renders content in the server and sends ready .html+js files to the browser. Browser still executes js to reload pages. Use when UI has little interactivity, when you need best SEO and faster loading.
SSG : Static Site Generating, all pages are already generated and rendered server side.
There are several popular frameworks that can be used for static site generation (SSG) and server-side rendering (SSR).
For SSG, some popular options include Gatsby, Next.js, and Jekyll. These frameworks use a variety of technologies, such as React, Vue, and Ruby, to generate static HTML pages from dynamic content.
For SSR, some popular options include Express, Flask, and Hapi. These frameworks use Node.js and other technologies to generate the HTML for a page on the server and send it to the client.
Overall, there are many different frameworks available for both SSG and SSR, and the best choice will depend on the specific needs and goals of the project. It is important to carefully evaluate the features and capabilities of each framework to determine which one is the best fit for the project.
The “bus factor” is the minimum number of team members that have to suddenly disappear from a project before the project stalls due to lack of knowledgeable or competent personnel. The bigger the better ( https://en.wikipedia.org/wiki/Bus_factor )
My oldest Email address : paul@sixcom.it, paul@cusun.sublink.org (I guess), 1990 Oldest reference to something written by me on the net : https://groups.google.com/g/comp.unix.questions/c/UwGUVEAFKz4/m/mzybPpn3mkwJ there should be something even older by I guess google does not have newsgroups from 1989/90 …
