zerojames

Thank you for sharing this! I didn't have the opportunity to use Reader. I have always wondered what made it stand out.

Congratulations on writing a book! That is a big deal.

I spend a lot of time writing blog posts, where the limited length (< 2k words) helps with sticking to a style. Longer proses are more difficult. You have more transitions to manage.

I mostly use direct language ("X is Y. This means..."). I try to be as concise as possible, but I sometimes I am more wordy than I need to be.

With that said, I pay attention to how I can be more welcoming "In this guide, we will..." (emphasis on "we"), "we are going to walk through" ("walk through" rather than "discuss", etc.), and so on.

In my personal writing, I like being more humorous where I can. I have an upcoming guide coming up on content deprecations which will start with:

    > Taylor Swift's lyric "'Cause we never go out of style" doesn't apply to documentation.

Everyone writes in their own way. This is to be embraced. There are so many words from which to choose. We can choose which ones we want!

Will fix! Here is the link that should be there: https://jamesg.blog/category/advent-of-technical-writing/

Not featured in this series but a precursor and canonical read is: https://jamesg.blog/2023/11/27/technical-writing/

I wrote some reflections in https://jamesg.blog/2023/11/27/technical-writing/ that cover the "what", "why", and a little bit of the "how" of technical writing.

If you have already decided "yes, I want to become a technical writer!", write, a lot. If your job doesn't involve writing, start a blog. Write about the technical challenges that interest you; the web, databases -- anything! Having public examples to which you can point will look great to employers.

This is incredible, Lexi. I have had a lot of fun learning about the low levels of networking; there are so many interesting details. Documenting those — and making them so intuitive, like you do here — is amazing.

Keep up the amazing work!

> it uses terms without defining them

After reading this, I wrote a blog post. It will be part of the series, but probably released in a few days. I have so many ideas to cover! Now it's past midnight though, so I should probably get some sleep!

Thank you for the ideas!

Having the engineer pair with someone who has never used the product before who also works in your org could help. I have a blog post coming up about this soon!

I wrote documentation for a product earlier this year. A colleague with limited Python knowledge tried out the product using my documentation live, on a call. I learned so much from the process. We found bugs, we noticed that our documentation didn't have one clear usage path, which was confusing, and more.

Watching someone work through your documentation was a bit uncomfortable, but it really helped me. I plan to do it again with another documentation project on my hands.

Also, your colleague may need more direct feedback. I have picked up a lot of tips from the person who edits my work. Sometimes, I have an "aha" moment when I'm like "hm, this approach really is better!" and I take it with me in all that I write after that.

> writing documentation in a conversational style

The medium really matters. If the course was more about tutorials, a conversational style can be appropriate, if kept in check. If you are documenting open source software, it is different. Your colleague probably picked up good tips, but the course may not have shown how to use them properly.

Good question! Getting Started is where I put the information someone needs to know to get started. This is based on two things:

1. The minimum amount of information someone needs to use a project. In this case, that is the "what is", and showing how to run fine-tuned models. 2. Generally useful information that someone can use to evaluate / understand the project. In this case, supported devices.

A reader could skip these if they know for what they are looking, but if someone is new to the project a Getting Started section equips them with what they need.

For Python packages generally, I like to include an abridged version of functionality in a quickstart / Getting Started section. Then, usage examples can have either their own page, or examples with example outputs that are in the code and are propagated up through automated docs. [1] [2]

For small packages, I usually fit all of it in a README; having a strong quickstart, in all cases, is essential. [3]

[1]: https://indieweb-utils.readthedocs.io/en/latest/indieauth.ht...

[2]: https://supervision.roboflow.com/annotators/#supervision.ann... (I didn't write this page, but I like the style and it is auto generated from docstrings)

[3]: https://microformats.github.io/mf2py/#quickstart

Day two of this series is out, too): https://jamesg.blog/2023/12/02/navigation-links/

Further reading on technical writers and startups (knowing your audience, role, and more): https://jamesg.blog/2023/11/27/technical-writing/

I welcome ideas for what I should write about in the series! I have a couple of exciting ideas to explore; more would be sincerely appreciated.

The ML field is doing work in that area: https://github.com/huggingface/safetensors

I have written a post about this: https://jamesg.blog/2023/11/27/technical-writing/

I am a technical writer and have been for ~4 years. I love the work that I do. I got started because I loved coding and writing.

I see my job as taking in as much information as possible and distilling it into what I think the target reader needs to know. Indeed, I am often asked to document projects just before they are out of the door. Taking ownership over that process, and thinking hard about how I should articulate information, is a delight.

That reader might be someone who is learning a skill (for whom I am writing a "how to"), or a customer who needs to know how to use a software package (for whom I am writing reference and quickstart documentation).

Technical writing has led to some interesting personal stories. An old friend found one of my technical articles while studying for a course; that warmed my heart. As I have written more, I get the occasional email from a student asking about my work.

Happy to answer more questions! (but, honestly, I should blog about this!)

As for getting started with technical writing, setting up a personal blog is a good idea. Document a project you have made in the past, whether it is a website and how you built it, a software library that you made, etc. Or contribute to existing documentation if you have expertise that you can lend (i.e. add a quickstart to a library you use and love, contribute to MDN if you notice something that could be improved).

I work in computer vision and like hearing about the latest thing. I have been finding LinkedIn increasingly useful as a way to learn about machine learning.

There are _a lot_ of posts that I have to scroll through of little to no value, but every so often I see a post by Yann LeCun or the lead developer advocate at TensorFlow or a paper someone has liked that catches my eye or a new model release.

"Machine learning LinkedIn", as it were, is a real thing; not sure whether this applies to other disciplines.

A colleague and I have been investigating how different LMMs stack up against GPT-4 with vision. We ran seven tests across five LLMs We found strong performance with Qwen-VL and CogVLM, although no LMM (including GPT-4 with vision) passed all of our tests.

I'm excited to see what the next year of LMMs bring!

This Week in Google is my favourite podcast (they don't talk too much about Google though, a recurring theme they mention in the show).

They have a great panel: a reporter from Wired, a journalism professor and author, a photographer (who is also the network community manager), Leo (who hosts the show) and a rotating set of guests.

I am interested in every show they produce.

This Week in Tech is also great, but I prefer the TWiG panel :)

The places in which a vision model is deployed are different than that of a language model.

A vision model may be deployed on cameras without an internet connection, with data retrieved later; a vision model may be used on camera streams in a factory; sports broadcasts on which you need low latency. In many cases, real-time -- or close to real-time -- performance is needed.

Fine-tuned models can deliver the requisite performance for vision tasks with relatively low computational power compared to the LLM equivalent. Vision weights are small relative to LLM weights.

LLMs are often deployed via API. This is practical for some vision applications (i.e. bulk processing), but for many use cases not being able to run on the edge is a dealbreaker.

Foundation models certainly have a place.

CLIP, for example, works fast, and may be used for a task like classification on videos. Where I see opportunity right now is in using foundation models to train fine-tuned models. The foundation model acts as an automatic labeling tool, then you can use that model to get your dataset. (Disclosure: I co-maintain a Python package that lets you do this, Autodistill -- https://github.com/autodistill/autodistill).

SAM (segmentation), CLIP (embeddings, classification), Grounding DINO (zero-shot object detection) in particular have a myriad of use cases, one of which is automated labeling.

I'm looking forward to seeing foundation models improve for all the opportunities that will bring!

This is a terrific project!

https://openai.com/blog/frontier-risk-and-preparedness provides more context.

https://blog.roboflow.com/openai-clip/ is a good high-level guide to what CLIP can do. (Disclosure: I work at Roboflow, but I did not author this piece.)

I just posted a comment :D

I work for a computer vision company. I use CLIP almost every day. Example use cases for which I have used CLIP:

  - Image classification
  - Automated labeling for classification models
  - Image clustering
  - Gathering images for model training that are sufficiently dissimilar from existing samples
  - Content moderation

CLIP is also being used widely in new research. SAM-CLIP, shared with me by my manager today, is using CLIP (https://arxiv.org/abs/2310.15308) and knowledge distillation for training a new model. I have seen references to CLIP throughout multimodal LLM papers, too, although my knowledge of multimodal model architectures is nascent.

I have been playing with MetaCLIP this afternoon and made https://github.com/autodistill/autodistill-metaclip as a pip installable version. The Facebook repository has some guidance but you have to pull the weights yourself, save them, etc.

My inference function (model.predict("image.png")) return an sv.Classifications object that you can load into supervision for processing (i.e. get top k) [1].

The paper [2] notes the following in terms of performance:

> In Table 4, we observe that MetaCLIP outperforms OpenAI CLIP on ImageNet and average accuracy across 26 tasks, for 3 model scales. With 400 million training data points on ViT-B/32, MetaCLIP outperforms CLIP by +2.1% on ImageNet and by +1.6% on average. On ViT-B/16, MetaCLIP outperforms CLIP by +2.5% on ImageNet and by +1.5% on average. On ViT-L/14, MetaCLIP outperforms CLIP by +0.7% on ImageNet and by +1.4% on average across the 26 tasks.

[1] https://github.com/autodistill/autodistill-metaclip [2] https://arxiv.org/pdf/2309.16671.pdf

Web Environment Integrity? https://en.m.wikipedia.org/wiki/Web_Environment_Integrity

I added some letters to a demo and made https://susam.net/cfr.html#B15FRCFE7R2F4C11BR3E6C2E3. Thank you for making this! I don't know how it works but it is fun!

I am interested! You should write about what you find interesting; never worry if it will interest a particular group.

This is impressive!

We have just added a section on this! TL;DR: GPT-4V isn't great at this task at the moment :)

This is now fixed. We have moved the images through to our website. Thank you for the report!

All: We got the HN hug on our images. This has now been fixed.

Thank you for posting the Related sections, Dan!

You are going to learn so much from this project!

I have had a lot of fun implementing (much smaller) web standards. I started with ones that had step-by-step implementation guides. It was one step in realizing that the web _is ours_! We can build it at every stage, from the web pages to the standards to the browsers.

Happy building!