This week weâre talking about by Postgres with Craig Kerstiens, Chief Product Officer at Crunchy Data, and a well known ambassador for Postgres. Just Postgres. Thatâs what this weekâs show is about.
Matched from the episode's transcript đ
Craig Kerstiens: Yeah, Iâm sure itâs not any better, with coin mining and other thingsâŚ
Tiago Mendes joins Mat, Jon, and Johnny to discuss eventual consistency and strategies for changing data at scale.
Matched from the episode's transcript đ
Jon Calhoun: Thereâs some witches or something, mixing up some brewsâŚ
Hugging Face is increasingly becomes the âhubâ of AI innovation. In this episode, Merve Noyan joins us to dive into this hub in more detail. We discuss automation around model cards, reproducibility, and the new community features. If you are wanting to engage with the wider AI community, this is the show for you!
Matched from the episode's transcript đ
Merve Noyan: Great question. I have met NLP at my senior year at university, actually. Literally, my first project was text mining and doing a classification using Naive Bayes in R about climate change sentiments. If people believe it or not, but I have scraped some tweets and classified them in a data science class that I have taken. And I was like, âIâm going to make this my job.â I later joined two bootcamps, did masters, and started working somewhere as a machine learning engineer. I did everything I could. I worked three years as a machine learning engineer, doing mostly natural language processing and also a bit of analytics on the side. I was building chatbots, I was doing information retrieval tools, and so forth, and I was using Hugging Face back then.
[04:07] Prior to that, prior to building information retrieval tools, and also like putting Hugging Face into my chatbot with the BERT embeddings and such, how I met Hugging Face was that I have watched Thomas Wolfâs video on the future of NLP. Heâs explaining it so well, and I have become a fan. Once I have seen him posting about this community sprint on datasets, I was like, âCan I join as well?â and then I started contributing to Hugging Face. Then I later tried my chances with the audio sprint as well. I met people over there and I have learned a lot of things. They have taught me about CI/CD styling, formatting, and contributing to open source, actually. It was my first time contributing to open source and I was so excited when my first PR got merged. I kept helping other people out over there and I was like, âIâm going to be that person that is going to help people out in the sprints.â [laughs]
Here are my notes from Day 2 of CodeConf 2011. You can also check out my notes from Day 1.
[Slides]
Andy is the guy who wrote ack, and he got to his main point right away: GitHub is great for developers, but itâs not great for end users. Itâs important that we take those users into account, because there are many more possible users of our software than there ever will be developers or community.
Itâs important that we realize that newcomers do not care about source code. They want to see three things:
Therefore, your project should have a project site. It needs a URL; theyâre cheap, and they let you change stuff later if you want to move hosts. This page needs to have these three things on it, to help your newbies.
A good and bad thing is that GitHub has such a low barrier to entry, that tons of new people are doing it. This means we need to be extra encouraging of our new users, and help them get involved in our projects. You should be extra gentle with patches from new people: brevity will be perceived as harsh. You should only accept patches that help your project, but accept patches from new people if at all possible, even if itâs a small or trivial change. That magical feeling of getting accepted will draw them in.
Make a project guide for your project: it needs to break down the project into small chunks, and provide direction and standards and a preferred workflow.
Also, donât forget to monitor your fork network, sometimes people build cool things and donât send you a pull request!
Finally, it all really boils down to this: put yourself in a newbieâs shoes. Make things good for them.
âIâm Seth, I abandon software. specifically oauth.â Seth talked a lot about the lifecycle of open source software, and the hows and whys of handing a project off to someone else.
Hereâs the outline of the four stages of the software development lifecycle, and the motivations for each step:
Itâs so easy to share code now, everyone is doing it, which leads to more abandoned projects. We need to examine the consequences of this, and learn how to give up projects gracefully.
âFarmville - Your Mom Loves This Shitâ
The beginning of this talk was one big ad for Farmville, frankly. âHereâs what Farmville is, hereâs why itâs awesome, we wrote an iOS client, it works the same way!â
She did talk at the end a little bit about things that are different from the web to iOS. Sprites were encoded from .swfs to .pngs. They use Cocos2D, which gives you a nice framework for building games on iOS.
One big thing that changes when you develop for an embedded device is memory constraints. Their biggest issue with this revolved around the animal sprites, which take up a lot of space. So they needed to be paged in and out, sometimes often.
They still used UIKit on top of the EAGLView that Cocos2D gives you, so that they could use UIKit to provide the usual kinds of menus and such.
For an alternate set of notes on this talk, John Garza sent us an email:
Amanda covered basic social gaming concepts, and why, she thought these types of games were important in the social landscape (the evolution of fbâs poke to an fb gameâs âgive a giftâ system). And the idea of connecting to your friends and family who you might not have time to connect with in the normal social way (messages, email, phone calls). Coming from Namco, and her work with launch game titles for iOS devices, she was tasked with creating the same easy of use experience in a native game client in order to preserve the type of gameplay that so many users already were used to on fb.
Farmville itself, is a basic isometric build-your-own-farm which makes use of the painterâs algorithm (or priority fill) to project a 3d scene onto a 2d plane.
Their plan was to go about creating a client that would not require a change of backend server code or the underlying server game code. One of the early roadblocks they came across was the obvious network latency with working with cell devices. To overcome that road block, they abstracted a transaction manager system to queue any type of specific game transaction and transport them to the game server in a non-blocking way so the game client wouldnât hold up with user.
Another obstacle was the sprites discussion mentioned in the summary, and the need to make sure some (but not all) graphics were cached locally on the device, and how they implemented a feasible way of pushing updates to sprite graphics as updates to in-game items are often large and frequent (monthly or sometimes every other week).
They ended up with an update xml file pointing to changed/added assets stored on game serves which were hashed-named graphics packages for each asset (using a weird not-so-good-quality sprite graphic format called ~PVR? - My notes are sparse on this point). Amanda spent a few moments lamenting on how xml was a poor solution for this job and in hindsight, json wouldâve been much better.
In the implementation side, besides the mentioned Cocos2d, Amanda also mentioned the development of FontLabel for incorporating custom fonts into pre-4.0 iOS applications, and how this package is still used today for backwards compatibility (post-4.0 now has this feature)
https://github.com/zynga/FontLabel
[Slides]
Confusion sinks startups, so we need to fight it. First thing that needs to be handled is the product itself, and what needs to be built. The second part is the technical challenges that happen with building said product.
Instagram came out of a project called burbn. It was an HTML5 app that did social/mobile/location stuff. The most asked question was âwhat are you guys?â You have to actually focus on something. And it took them three months to get less confused.
They did this by doing four things:
Ideation is about creating your original ideas. They donât code until they sketch out a UI. And theyâve built and thrown away entire features on paper. This is an example of âmaking wrong less painful.â
Validation is about getting feedback from users, to confirm that your thoughts are true. Every social app should go through âthe bar exam.â If you canât explain it to someone at a bar, then you need to simplify it.
Building is pretty obvious, but there are still some tricks. You still have to be able to learn while you build stuff. You can do this with a tight feedback loop, iterating on one week cycles.
You need to be âproud but embarassedâ about your first launch. Do a few features, and do them really well, to build your âminimalist viable product.â
âOne day out in the real world is worth one month of guessing.â
âUse your friends and make some new onesâ (for your beta)
All of this is about product uncertainty. As for technical uncertainty, the main question is âAre we building it the right way?â
Focus, and keep your team small. Ask yourself what your company is actually about. Your framework is not going to be the most important bottleneck. Stand on the source code of giants. Experiment with quick projects. The anti-pattern is âLetâs re-write our entire site.â An interesting way to think about features is âCould we rip this out in 20 minutes if itâs bad?â
If people were talking about Codaâs talk on Day 1, everyone was excited about Jeremy for Day 2. I think a lot of people were blindsided, they didnât know what was coming, but Convore BLEW UP for this talk. I canât hope to do it true justice, but hereâs what I managed to pull out. Oh, and you can also see some other notes here, too.
Luckily, I managed to get my hands on a copy of the audio recording of my talk. Please give it a listen.
EDIT: Jeremy posted his slides.
âWhat makes code strange?â Thereâs lots of interesting things about code that we take for granted. Any given MacBook has 50 years of software history running on it at different times.
We use languages like Ruby Python or JS because they let us write code like literature. It fits the way we think. Letâs be honest, we donât use Ruby for engineering reasons.
Dijkstra gives us lots of reasons to treat code as something different than other kinds of literature. âI do not know of any other technology covering a ratio of 10^10.â
How big is the spec for you code when you print it out? If youâve never run code, is it still code?
âBy evoking the need for deep conceptual hierarchies, the automatic computer confronts us with a radically new intellectual challenge that has no precedent in our history.â Code is a fundamentally new thing.
Code is logic. Haskell, no IO, did it ever run? Knuthâs definition of software.
Code as Law. We set up constraints on the variables and objects in our code, and it defines the possible space of our bits. When we write code, weâre taking the infinite blank space of our hard drives and CPUs and narrowing them down into something meaningful. In the machine, code is the only possible law.
Code as Art. Knuth was all about this. âScience is knowledge which we understand so well we can teach it to a computer; and if we donât understand something it is an art to deal with it.â Concrete arts vs Abstract arts.
Code has a dual audience. The machine and the reader.
âThe competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humilityâŚâ - Dijkstra
The history of programming languages is all about âhow do we address both audiences.â
Dijkstraâs Structured Programming vs Knuthâs Literate Programming.
Code as literature. âMeaning belongs to a text or to a program to the extent that it acts upon intelligence in a particular way.â We say that a textual work is âliteraryâ if it contains a high density of meaning.
âWhile we count the lines of code we use, the battles here are fought, won, or lost on how much power of meaning lies under the syntactic forms.â - Alan Kay
Code is still writing. We use literary abstractions in code. He gave three or four examples, but I couldnât really take notes fast enough to do them justice. My bad!
Object Orientation is an explicit Biological Metaphor.
Code as Commons. We are participating in a society, reading and writing code is about being a participant in a civic society.
âSome programs are elegant, some are exquisite, some are sparkling. My claim is that it is possible to write grand programs, noble programs, truly magnificent ones.â - Knuth
She was checking out duplication in CSS of big websites. Facebook was one, Salesforce was another. For example, Salesforce has 3,668 padding declarations. She started wondering how many other people were being sloppy with CSS, and she looked at the Alexa top 1000 websites. !important is a code smell, and the biggest site had 518 declarations of it! float usually means that you havenât build up the proper abstractions for your design. Use grids instead. font-size is also something that people use far too many of. 13px bold is basically the same as 14px. The worst offender for this was 889. 25% had over 100.
Insanity: doing the same thing over and over and expecting different results.
Three best practice myths:
She talked about CSS specificity, which is still black magic to me, because Iâm a CSS noob. She then talked about ways to modify elements in certain parts of the page in the best way. Frankly, Iâm not sure what the best way is to summarize these slides, so hopefully someone else will have a better one for this talk. :)
She did end up bringing up something we all do, but feel bad about it: coding via Firebug.
Once you get really deep into CSS, you can easily end up in a very hostile environment for your code: youâve got two layers to develop, and itâs really hard to tell which rules take precedence, and it becomes basically impossible to get the look and feel that youâre going for.
How do we solve all of these problems?
By doing the right thing, Facebook was able to cut their average CSS bytes per page by 19% after gzip and html bytes per page by 44% before gzip.
Will was a last minute addition in the lineup, so he didnât have slides.
âThey always say to start with a joke, so: git submodule support.â
He pretty much gave a slightly extended version of his latest blog post, Farming vs Mining. So Iâll just leave that up as summary.
All thatâs left is dinner and drinking, so Iâm out! I hope youâve enjoyed these summaries, and Iâm really looking forward to an awesome CodeConf next year.
In our ops & infra world, we learn to optimise for redundancy, for mean time to recovery and for graceful degradation. We instinctively recognise single points of failure, and try to mitigate the risks associated with them.
For some years now, Daniel Vassallo has been doing the same, but in the context of life & work. Daniel talks about the role of randomness, about learning from small wins & about optimising for a lifestyle that matches your true preferences. Apparently, ideas too should be treated like cattle, not pets.
Matched from the episode's transcript đ
Daniel Vassallo: [30:03] There are a few. Iâm not sure how willing they are for me to share publicly their numbers, or whatever⌠And success, again, is very relative. To some people â many people in our community still have a full-time job, and theyâre not necessarily looking for, but they just wanted to have a portfolio of side projects. And these might be making sometimes just a few hundred dollars, maybe $1,000 a month, and for them itâs a big success, right? Itâs something supplementing their income, exposing them to new things, giving them a fallback, so that if they get laid off or something were to happen, they donât have to start from scratch. That is very, very reassuring.
Thereâs a few others who, yes, have taken a similar path, of starting with educational projects, mixing in software projects, other things, and going in many different directions, and have some highly unexpected successes in areas that they least expected⌠And to others, which I still â this might sound may be a bit⌠I donât know what to call it; maybe a bit bizarre, or maybe⌠I donât know. But for what Iâm doing in the Small Bets community, I think even if people havenât had success yet, the fact that theyâve been exposed to a different way of doing things is already, I believe, a success. The fact that the inspiration â âHereâs another way of doing thingsâ, itâs knowledge. Itâs some amount of guidance. And again, we have 2,000 members, many people join, in very different circumstances in their lives⌠Some people are curious, some people are tempted, some already are taking the plunge and working for themselves, want to make things better⌠So there are many different arrangements. But having a place where you can go share ideas, get feedback, have a support network of people who can help you sort of see a strategy that is much more prudent, and reason about it on a very pure, fundamental level - I think itâs very empowering. I try to measure success that way.
I like to use the example - and I shared it on our Discord recently - related to woodworking. Recently, I bought a book about how to make your own doors. Well, recently - about a year ago. And I read it all, I enjoyed it, I learned a lot, but I never made my own door. And maybe I never will. Was that a regretted purchase? No. Actually, I really enjoyed it. Actually, recently I was recommending the same book to other people; money well spent. It taught me a few techniques⌠But if the author of the book were to make a survey of who actually put these techniques in practice, I would have to answer no; I havenât, and maybe I never would. But it was still a very satisfying purchase; the time I spent reading it was very well spent, and I recommend it⌠But what it gave me - again, showing me how a door is made, I learned something, some techniques here and there⌠And also knowing that if I did want to make a door, Iâm not going to start from scratch. I have a reference that I could refer to.
I think itâs a similar thing over here - out of the 2000 members, Iâm sure maybe only a very small percentage actually put everything in action, and are living off their projects. But thereâs a wide spectrum in between; some people are just getting started, some are just waiting for the right circumstances to happen, but they have something to fall onto if they wanted to.
Nader Dabit shares his motivation and experience on recently transitioning to focus on technologies and communities that support the decentralized internet. In this hot topics discussion, we cover all the buzz words youâve likely heard over the past year. We have honest and nuanced conversations about the world of Ethereum, Cryptocurrencies, NFTs, DAOs, and Web3. Hype or hit? Youâll have to tune in to find out.
Matched from the episode's transcript đ
Nader Dabit: Some of the DAOs allow you to just join for free, some of them ask you to mint some type of token⌠But either way, you have to have, for the most part, some type of token to get in. And the reason that thatâs the case is to kind of give ownership to everyone thatâs there, and also provide them a way to liquidate that ownership.
So for a token, you can basically sell that, either on some digital exchange, or maybe like an NFT would be like OpenSea, or some type of NFT marketplace⌠But yeah, most of the time you can get a token or buy a few ERC20 tokens, or work for those tokens by participating in the Discord, and then you can participate in that way.
For the Developer DAO, which is the DAO that I have created for developers, the token is completely free. All you have to do is just go to the website and mint the token. And you do have to pay the Ethereum transaction costs. When you pay that cost, you get that token sent to your wallet.
And really, the reason that there is any type of cost at all is to kind of have some type of way to prevent civil resistance⌠Because if this token is gonna be worth money at some point, whatâs to stop someone from minting all 8,000 of those for themselves? Like, how do we equally distribute ownership between a large number of people? Well, there is some type of way that we can do that with needing someone to mint.
But what Iâve been doing is actually setting aside a few thousand of my own dollars, and just minting those and sending them to people around the world that canât afford even the $20 minting cost. But that way I know that that person is real, and that theyâre kind of in it to be part of the community, and theyâre not just in there to kind of speculate.
Earlier this year on February 2nd, 2020 Jon Evans and his team of archivists took a snapshot of all active public repositories on GitHub and sent it to a decommissioned coal mine in the Svalbard archipelago where it will be stored for the next 1,000 years.
On this episode, Jon chats with Jerod all about the GitHub Archive Program and how theyâre preserving open source software for future generations.
Matched from the episode's transcript đ
Jon Evans: âŚwhich had just recently built, in cooperation with the Norwegian government, or this mining company owned by the Norwegian government, a vault beneath an Arctic mountain in Svalbard. That was obviously of some interest, so we pursued things further with them, and it turned out that was gonna be a pretty good fit⌠Which is good, because building an entire, elaborate super-structure apparatus for archival is obviously a non-trivial job, so it was kind of nice that someone else had done a lot of that work for us.
Weâre listening! This weekâs experimental, super-brief Monday edition of âThe Changelogâ has the following new features: Itâs longer, thereâs no background music during the stories, and it includes stories previously not featured in the newsletter.
If you like this better than the last one, would listen to it, and want us to keep it going⌠let us know in the comments or by tweeting @changelog!
Matched from the episode's transcript đ
Jerod Santo: Hello friends, Iâm Jerod and this is Changelog News for the week of Monday, July 4th, 2022. But weâre shipping out on Tuesday instead of Monday, because [FreedomâŚ! 00:00:16.11]
First up, thanks to everyone for sharing your thoughts on this little experiment of ours. We are listening and adapting, so please continue with the feedback. Hereâs whatâs different this time around. One, almost everyone said to make it longer. [As you wish⌠00:00:37.10] This episode is about twice as long as last weekâs.
Two - many of you also read Changelog Weekly, and since weâre covering the most interesting links from Sundayâs edition of the newsletter, it makes the audio version less new or interesting. So we are now mixing in stories that we havenât previously covered. Hopefully, that keeps it fresh for everybody.
Three, many of you think the music bed is distracting, and asked us to turn it lower, or turn it off altogether. So letâs try it without, and see how that sounds. Nice and quiet.
Okay, letâs get into the news.
On DX tips, Swyx writes about the 4.5 kinds of dev tools platforms. This is his attempt to make sense of the overwhelming world of developer tooling. If you work for or invest in dev tool startups, I think this mental model is a good one. What are the 4.5? One, application platforms that make the user productive. Two, infrastructure platforms make the application run. Three, data platforms make the data useful. Four, developer platforms make developers productive. And the point five, internal services with cross-cutting needs to interface with every platform. Those are his high-level conclusions. Read the whole article for his thinking behind the matter.
Did you know there are things you should know about databases? Lots of things. And did you also know there is an excellent - and I mean, excellent post on architecturenotes.co to teach you some of those things. Itâs focused mostly on indexes and transactions, explaining them in great detail with some seriously impressive diagrams to make sure it all clicks. Not much else to say about this one, except that it was the number one clicked link in the newsletter, and thereâs a link for you to click in the show notes.
Brandon Rhodes wants you to start all of your commands with a comma. Why is that? If you have your own Bin directory somewhere in your path, which you probably should, and you put all your own little scripts and executable bits in there, like you probably should, eventually youâll hit a problem or your script names start to conflict with the built-in and bundled commands. But if you start all your commands with a comma, like Brandon does, this problem melts away. [You cursed brat! Look what youâve done! Iâm melting, melting. Ohhhhh, what a world, what a world. 00:02:56.22]
As a bonus, team this technique with tab completion, and itâs super-easy to browse your collection of commands. Just type comma, then tab, and there they are.
Lobsters turns ten. Over the weekend, the websiteâs creator, Joshua Stein, tweeted âTen years ago today, I âpooped outâ a better version of Hacker News in my spare time.â As Thomas Ptacek eloquently put it. It didnât really mature into the thing that I hoped it would, and I donât use it much anymore, but Iâm happy some people are still finding it a nice place to be.
Over on the site itself, current administrator Peter Bhat Harkins says âOver that time, our community of 15,013 users have submitted 87,530 stories, written 381,460 comments, and cast 2,536,117 votes.â Thatâs a lot. I am a fan of the site, which usually features more esoteric and engineering-heavy posts than other tech aggregators. The conversations there can still get toxic from time to time, but were on the internet is that not the case? Seriously, if you know of such a place, holler at me. [I want to go to there 00:04:18.09]
[04:20] James Hawkins and his team at PostHog have interviewed 725 people, and one of his big takeaways is âItâs normal for candidates not to ask harder questions about our company, so they usually miss out on a chance to 1) de-risk our companyâs performance, and 2) increase the chances theyâll like working here.â So he shares some really important job interview questions engineers should ask, but donât. Questions like âDoes the company have product-market fit? How much runway does the company have? Whatâs the culture like?â and a whole bunch more. Definitely worth a bookmark for the next time youâre job shopping.
Go Time listeners already know this, but for the rest of you, our recent episode with Ron Evans a.k.a. @deadprogram is just too good to miss, even if Go isnât your thing. Hereâs the conceit - the year is 2053; the tabs versus spaces wars are long over. Ron Evans is the only Go programmer still alive on earth. All he does is maintain old Go code. Itâs terrible. He must find a way to warn his fellow gophers before itâs too late. Good thing he finally got that PDQ transmission system working. What results is a hilarious and somehow still insightful conversation with so many funny moments like this one about the future of social media.
âYou know, when youâre building something thatâs gonna survive a two year trip to Mars, believe me, your mp3s sound pretty funny by the time the ship gets to its destination⌠Or so Iâve been told. I donât know, actually those might be AIs sending back those reports. There might even be no humans that survived the trip. Thereâs a rumor going around theyâre all just AIs.â âHowâs it going around? Whoâs it going around?â âSocial media still exists in 2053.â âOh, thank goodness. I donât know what youâd do without it.â âI use Minder. You know, itâs where youâre allowed to dump your actual mind directly.â âThatâs cool.â âIs it text? Is it visual?â Itâs more like a feeling.â âItâs just Hex.â âRemember the feeling you used to get when there was somebody being wrong on the internet? Itâs like that all the time.â âIs it XML though?â âNo, you just plug directly into your brain-computer interface, and youâre just really mad right away.â âOh, I love it.â âYeah, itâs beautiful.â
Listen to the rest in our Go time feed, or on the web at Gotime.fm/235.
Last up for today. Upptime. Upptime. No, I wasnât stuttering. [Did I stutter? 00:06:43.00] Thatâs U-p-p-t-i-m-e. Thatâs how you say that, right,? A super-cool uptime monitor and status page powered entirely by GitHub. It uses GitHub Actions as the uptime monitor itself, checking your website every five minutes. GitHub issues for incident reports, opening new ones when endpoints are down, and assigning team members appropriately, and GitHub Pages for a status website built with Svelte and Sapper. This project is not affiliated with or endorsed by GitHub, but it is super-cool, super-free, and endorsed by over 1,000 people who have set it up for themselves.
Thatâs the news for now. Let us know in the comments if you liked this better than last week; or worse, or whatever. Seriously, we do want to hear from you. We have an excellent conversation coming up for you on Friday. Brian Cantrell from Oxide Computer joins the show for a deep-dive on their attempt to build servers as they should be - hardware, with the software baked in for running infrastructure at scale. Adamâs on vacation this week, so I have a special guest/co-host joining us as well. Can you guess who? Weâll talk to you then.
In a world where an ex-hit-man named John Wick comes out of retirement to track down the gangsters that killed his dog and stole his car â three die-hard fans (Adam, Jerod, and Brett) spend nearly 2 hours discussing the John Wick trilogy and then some.
Matched from the episode's transcript đ
Jerod Santo: [01:03:41.06] We might be mixing metaphors here. Well, if thatâs the case, maybe weâll see the continued slide into convolutedness of John Wick, because I think The Matrix Reloaded is quintessential at taking a plotline and just mixing it and matching it, and going deeper and adding lore, to a point where itâs incomprehensible. So I hope that doesnât happen. But I think it would be cool if at the end of the last John Wick, whatever number that happens to be, he decides to retire and become a computer hacker, and he goes by Neo, you know?
Charity Majors joined the show to talk about debugging complex systems, using go to save oneâs sanity, hiring smart people who can learn, and collectively working to make âon-callâ life not miserable.
Matched from the episode's transcript đ
Erik St. Martin: Yeah, so to explain what the limitation is - the way this actually works is all of us are on Skype and we are all called by different Skype accounts that are all running on separate Mac minis that are all mixed together in a mixing port that Adam Stacoviak of Changelog does. So heâs hiding behind the curtains until we say goodbye, and then he joinsâŚ
This one is for Jerod since heâs such a Nick Miller fan đ¤Ł
Miller is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON
There are a variety of new projects working to create a healthier Web: from fighting censorship in oppressive countries, to solving pressing issues of privacy, to creating a Web entirely run by users. Come enjoy two days of immersive, hands-on workshops where you get to try out some of the latest decentralized web technologies for yourself.
And itâs free!
The Changelog team will have a BIG presence at All Things Open in October. To celebrate, weâre giving away FREE tickets!
đ Get yer tickets for React Amsterdam, the biggest React conference in the world! Weâre excited to collaborate with this awesome conf to bring you a live recording of JS Party from the event stage. Trust me, that FOMO youâre experiencing right now is very real đ
We talked with Eugen Rochko, the creator of Mastodon, about where Mastodon came from the problem it aimed to solve. How itâs not exactly Twitter alternative, although thatâs its known claim to fame. Why itâs probably not going anywhere. The ins-and-outs of federation, getting started, running an instance, why you would want to â cool stuff youâve never considered could be built on top of Mastodon. And finally, the story behind naming posted content a âtootâ.
Join us on a journey to make believe worlds with our good friend Mat Ryer. The assignment; we each get to make up a new world where we invent a new gadget and declare a new rule. This episode is sure to delight loyal fans and especially those who enjoy Mat Ryer on the show and a good/bad song or two.
Our award-winning JS Party game show is back with a new name, a new channel, and the same olâ survey-response-guessing fun! The JS Party crew join us to see who knows yâall best. Survey says!
Kris Brandow & Matthew Sanabria from Fallthrough.fm join Jerod to discuss tools weâre switching to, whether or not Go is still a great systems programming language choice, user-centric documentation, the need for archivists & more.
Mat gathers the entire cast (sans Natalie, sadly) alongside our producer, Jerod Santo, for one last Go Time. Thatâs right, this is Go Timeâs finale episode. After eight years and 340 episodes, we are going out on top. Join us one last time, you wonât regret it!
We share our feelings, reminisce on the good times, list some of our favorite moments & share a few opinions, which may (or may not) be unpopular. đ
Chris Coyier and Dave Rupert join Adam and Jerod for a ShopTalk & Friends conversation on the viability of the web, making content, ads to support that content, Codepenâs future plans, books, side quests, and social networks devaluing links.
Our friends Johannes Schickling & James Long join us to discuss the movement of local-first, its pros and cons, the tradeoffs, and the path to the warming waters of mostly local apps.
Recently, four pillars of the JavaScript community (James Snell, Natalia Venditto, Michael Dawson & Matteo Collina) teamed up to create a resource that lays out nine principles for doing Node.js right in enterprise environments. On this episode, Natalia & Matteo join Jerod to discuss all nine.
We join the Whiskey Web and Whatnot podcast live from the hallway track at All Things Open 2024. Topics include: Chianti, content creation, open source, fake jobs, cancel culture, Silicon Valley (ding), frontend frustrations, the Roman empire & more.
We are on the other side of âbig dataâ hype, but what is the future of analytics and how does AI fit in? Till and Adithya from MotherDuck join us to discuss why DuckDB is taking the analytics and AI world by storm. We dive into what makes DuckDB, a free, in-process SQL OLAP database management system, unique including its ability to execute lighting fast analytics queries against a variety of data sources, even on your laptop! Along the way we dig into the intersections with AI, such as text-to-sql, vector search, and AI-driven SQL query correction.
The last time we did a roundup of our unpopular opinion polls, it was November of 2021!
Thatâs too long ago, so today we fix that bug. Join Go Time producer, Jerod Santo, as he ranks & reviews the most (un)popular opinions of 2022.
As Argilla puts it: âData quality is what makes or breaks AI.â However, what exactly does this mean and how can AI team probably collaborate with domain experts towards improved data quality? David Berenstein & Ben Burtenshaw, who are building Argilla & Distilabel at Hugging Face, join us to dig into these topics along with synthetic data generation & AI-generated labeling / feedback.
In this episode, we will be talking to Russ Cox, who joined the Go team at Google in 2008 and has been the Go project tech lead since 2012, about stepping back & handing over the reins to Austin Clements, who will also join us! We also have Cherry Mui, who is stepping into Austinâs previous role as tech lead of the âGo coreâ.
Join Johnny as he dives into the world of home automation with Ricardo Gerardi & Mike Riley, two tinkerers whoâve taken the plunge with Go. We explore the challenges (and the fun) they encounter along the way. If youâre interested in automating your home (or working with micro controllers) come learn how to get started!
What if your infrastructure diagram was responsible for the actual infrastructure?! John Watson & Scott Prutton from System Initiative join Justin & Autumn to discuss.
Raphael Landaverde & Jake Shirley work on Minecraft full-time. How cool is that?! On this episode, they join Jerod to tell us all about the web tech that drives Minecraftâs scripting infrastructure, how they incrementally change a massive / always-moving target, the best / worst parts of the job & much more.
