I think BeautifulSoup is great but it's more of a set of building blocks that requires developers to implement their custom scraping logic. Trafilatura is awesome because it just works out of the box for most common tasks related to web scraping.
I should, perhaps, add an FAQ section addressing the hows and whys of Griptape :)
In short, Griptape is different from LangChain in the following ways:
- Instead of chained agents, it uses more general-purpose DAGs and pipelines. Think of it as Airflow for LLMs. It still implements chain of thought logic for prompt workflow steps that use tools but it also supports any kind of input and output (think images, audio, etc.).
- Griptape tools are designed to be decoupled from the caller logic and execution environments. For example, tools can be easily run in a Docker container or a Lambda function (as opposed to just YOLOing LLM-generated Python code on the local box).
- Tools can be plugged into other LLM frameworks through adapters. For example, you can convert any Griptape tool into a LangChain tool or generate a ChatGPT Plugin API with a single line of code. This is the only place Griptape actually references LangChain in code, afaik :)
Issues do need to be moved from a private Trello into GitHub (still early days...)—I can ping when that's done—are you on Griptape Discord?
The WebScraper tool uses Trafilatura [1] to scrape and parse HTML—nothing too fancy. "Scraping" a React site would require a totally different approach, probably something more akin to Adept's ACT-1 [2].
I run a local chat app built with Griptape and I use it to give me summaries of web pages or answer specific questions all the time :)
1. Currently, if I install something in the notebook, does it get re-installed every time the pipeline is run? Is there any way to "snapshot" the state of the container?
2. Where is the data stored between the steps?
3. How well-integrated is it with AWS cloud primitives such as EC2 instances, EFS, and S3?
It seems like it uses Docker instead of custom cluster-building logic. I'm not sure if there are differences between how it slows down the network and creates partitions.
Hi! I launched OpsLog a few weeks ago. Its purpose is to analyze team's on-call and pull request data to quantify operations impact and software engineering progress.
I'd love to get some feedback on the product and the problem that I'm trying to solve. I'm also wondering what HN folks generally struggle with when it comes to analyzing and improving on-call at the team and org levels.
I'm not sure I agree with the listed reasons. From what I understood, the author tries to prove that "SaaS is eating SaaS" and SaaS abundance/switching costs are prohibitive to new SaaS ventures. This doesn't seem like a very good argument for "SaaS is dying." May be, it's better suited for "it's becoming more difficult to enter the SaaS game."
It's not exactly news but it's nice to see it broken down in a cohesive way.
> Because the article assumes or implies the conclusion that there are a huge number of vulnerable Rails apps.
I think the article quite clearly indicates where all data points came from (Hakiri Facets) and then analyzes them. There is a post scriptum at the end that encourages readers to not evaluate their or any other projects based on the number of CVE vulnerabilities and goes into detail why it's not always a great idea.
I don't understand... The article first analyzes apps that use a certain number of vulnerable gems. Sure, most of them are probably patched, but it doesn't change the fact that certain apps use old unpatched versions of these gems.
The second part focuses on historical vulnerability data for Ruby gems.