WingNews logo WingNews GitHub [2]

SamyPesse's comments

SamyPesse | 2 years ago | on: New GitBook: Capture Knowledge from Slack, VS Code and AI Content Insights

Yes LLMs are an amazing technological breakthrough for knowledge base and document solutions.

You have a good understanding of what we are doing :)

With snippets:

* You can save Slack thread as a new document in GitBook; the document will be generated by a LLM (it's not a plain dump of the messages).

* You can record your work on VS Code (+ audio), and we'll translate it as a document (snippet)

With Insights:

* We analyze content (we have customers with more than 10000 pages in their docs) and identify contradictions or duplicate

* We don't auto-fix them yet, but it's planned ;)

With AI Search:

* We leverage LLM and a vector database to provide complete answers with sources to natural language questions

SamyPesse | 2 years ago

Today I’m proud to introduce the public alpha of GitBook Lens — a new semantic search tool powered by AI.

Lens indexes the content of documentations hosted on the platform, and provides an interface to ask questions. It’ll scan your documentation and give you a simple, semantic answer using OpenAI — with clickable references if you want to dive deeper.

While Lens is in open alpha, anyone can activate it at no extra cost.

We also provide an API to integrate GitBook Lens in your website / application.

SamyPesse | 3 years ago | on: Lessons from building Plausible Analytics to $1.2M ARR in public

GitBook founder here :)

We are working on multiple aspects of the products that should cover a lot of this (improved i18n, SEO, faster rendering)!

Would love to get your feedback on what you would like to see improved exactly on our SEO friendliness and i18n support. We have an open GitHub community for feedback; https://github.com/GitbookIO/community/discussions

And for anyone, if you are interested in building a "A SaaS to host product guides ", we are hiring engineers/designers/builders: https://jobs.gitbook.com/ :)

SamyPesse | 3 years ago | on: GitBook bypassing Cloudflare DNS to route traffic to their domain

We only remove the domain from Cloudflare when the content is deleted. The main reason is to avoid broken links when users update their domain on GitBook.

Ex: 1. You configure docs.mycompany.com with your GitBook space 2. You share links to docs.mycompany.com on social medias 3. You update the domain to docs.anothercompany.com 4. It's better if the docs.mycompany.com links can continue working until you remove the DNS entry

In summary, we want the users to decide through their DNS config when GitBook should serve the content or not to avoid breaking links without an intentional action from the user.

Unfortunately, because of how Cloudflare doesn't use the DNS configuration to decide where to route the traffic, it causes issues atm. We'll look at what we can do on our side to mitigate this.

SamyPesse | 3 years ago | on: GitBook bypassing Cloudflare DNS to route traffic to their domain

GitBook CEO, here.

We use Cloudflare to serve HTTPS traffic for all custom hostnames configured by our users.

When a user configures a custom hostname, they point their DNS via CNAME to one of our domains (which, at the end of the chain points to Cloudflare). We then request Cloudflare (using their Cloudflare for SaaS product) to generate an SSL certificate for this hostname and serve the traffic properly.

When users move away from GitBook, they often don't remove their content from GitBook and only change the DNS on their side. We don't request to remove the hostname from Cloudflare for SaaS until the content is deleted from GitBook, as the goal is to avoid breaking links for URLs that are still pointing to GitBook.

We'd expect Cloudflare to always use the DNS setup of the domain as the primary factor for deciding where to route the traffic.

We don't know the rationale behind why Cloudflare routing continues internally routing the traffic to GitBook when the domain is no longer pointing to the GitBook hostname. But it is not us doing that intentionally.

Our support can help unblock this situation by manually removing this domain from our Cloudflare for SaaS. You can reach out at [email protected].

SamyPesse | 5 years ago | on: Google Domains blocking all Gitbook URLS: post-mortem

We don't host user content under the gitbook.com, or at least we've stopped doing it a few years ago.

User content is stored under *.gitbook.io, similar to GitHub.

Google blocked all domains that contained "gitbook" in our account, even ones that are used for some infrastructure and are not accessible by the public. We don't know the exact reason for this, maybe they've blocked gitbook.com because we still have some redirect for content that was hosted under it years ago.

And yes we are going to make changes to host our status page under another domain.

SamyPesse | 5 years ago | on: Google Domains blocking all Gitbook URLS: post-mortem

Yes, after 6h without getting much responses from Google Domains support, we just got a notification that they unblocked our domains.

We are working on making sure that everything is correctly working.

Workaround that we've setup to allow our users to still access the platform through different hostnames will continue working.

SamyPesse | 5 years ago | on: Google Domains blocking all Gitbook URLS: post-mortem

GitBook CTO here:

Our production domains (gitbook.com and gitbook.io) have been blocked and locked by our registrar (Google Domains).

None of our infrastructure is impacted, all user content and databases are safe; our domains simply blocked by a heavy handed policy.

As mentioned on Twitter, we are all hands working with Google to fix this issues ASAP. We'll then share an in-depth post-mortem

https://twitter.com/GitBookStatus/status/1268554857411227648

SamyPesse | 12 years ago | on: Optimizing large selector sets

"Both of these libraries should be unnecessary and hopefully obsoleted by browsers someday. Browsers already implement techniques like this to process CSS styles efficiently. It's still unfortunate we have no native implementation of declarative event handlers, even though people have been doing this since 2006."

I think they believe jQuery will rapidly become the past so no reason to merge it.

page 1
more