pselbert

I’ve spent a large portion of the past month working with ffmpeg. We are using it to repair, concat, and mux an arbitrary number of overlapping audio and video streams recorded via WebRTC. While this sounds straight forward on the face of it, the interplay of filters and controls is impossible to predict without extensive experience.

To my knowledge ffmpeg is the only tool that could possibly do this. It took a whole lot of reading man pages, bug trackers, stack exchange and various online sources to stitch together the necessary info. This seems like a great resource to learn what the tool is really doing and skip scrambling for information so much.

On the face of it $76m seems like a staggering amount of money. Then we learn that the foundation dedicates $3b a year, and this seems like a drop in the bucket.

Amazing what massively focused resources can accomplish.

Just recently I thought to myself "it has been a long time since I saw the Github Unicorn". As it turns out, I didn't really miss it at all.

Regarding the centralized nature of Github: it is the centralized communication that is a problem, not the ability to share code. I can easily send a patch to somebody on my team, but that doesn't help me review a PR, reply to comments, trigger a CI build, or initiate a deploy.

Code sharing is only a small part of what a team relies on Github for.

A non profit that I support has been relying on Yahoo for exchange rate information for nearly 10 years. I knew when I inherited the app that this was imminent, so it wasn’t too surprising.

There are plenty of alternative paid APIs out there that made switching easy. Hopefully others who had legacy developers integrate with the financial APIs are able to switch easily too.

Precisely. While I happen to enjoy building IKEA furniture (in small doses), I would be pleased never to pick it up from a store ever again.

The complement of being " really useful" never bothered me.

My kids are a bit too old for Thomas now, but we still say people are "causing confusion and delay" when they derail the rest of the family.

Years ago when Phoenix was adding JS support I lobbied Chris McCord to go with Webpack. He took a lengthy look at the setup/configuration process for all of the popular build tools and ended up choosing Brunch. For most tasks it is a great choice, and an excellent default for a "batteries included" web framework.

This is precisely the kind of article I hope for when I browse the front page.

Thank you for all the effort you put into writing this. It is clearly the product of a lot of effort and craft.

Every time I participate in a security audit for some enterprise contract I have to explain and defend why we don't enforce complexity and rotation rules.

Lately citing the NSA's change in position has been convincing enough and we don't get nearly as much push back.

You can install JOE on macOS through homebrew. Running "brew install joe" begins installing version 4.4

When I read the headline I thought it would be a link to Dan Luu's recent post [1]. Not too surprising that it was actually submitted by him!

The most amazing part of this is the JOE editor. Performance and memory aside, I'm astounded it has been maintained by the same person since 1988! [2]

[1]: https://danluu.com/term-latency/ [2]: http://joe-editor.sourceforge.net/

He used the term "preferred", in the past tense. I think we can safely assume that he has a different passcode or device now.

AS3 was like learning Java, but with the lifecycle gotchas of JavaScript. Ten years ago it offered everything that JS did, except it required static compilation. The development speed of JS+CSS was vastly better than with pure AS.

I'll slightly mourne the passing of Flash.

The "final few pages" are entirely module reference for zlib so that probably isn't what is referenced. Prior to that are miscellaneous bits about debugging, tracing, code-reloading etc.

I have version P5.0 from 2011 though, so it could be wrong altogether.

In Erlang you usually run one "node" per machine, though you can call between them with transparent RPC.

This library uses one "process" per neuron for concurrency. Processes are extremely lightweight and entirely unrelated to system processes or threads.

There isn't any need for that. Hex is becoming the de facto package manager for the Erlang ecosystem. You can easily install this as a dependency and call it from your Elixir code.

There is a practical, functional GraphQL spec that has multiple client and server implementations. Regardless of whether Facebook continues to develop clients or maintains stewardship of the spec, GraphQL has a lengthy future ahead.

The most recent open issue is from 6 months ago and posits whether the project is still active. It definitely feels "experimental", but a bit outdated already.

Every time there is a post regarding Ruby implementations and their speed (or lack thereof) I know there will be sobering comments from chrisseaton.

As much as I reach for more performant languages, I still need to work with Ruby on a daily basis. I really appreciate the ongoing work done by you and others to keep the ecosystem alive and prosperous.

FastMail is my first pinned tab. It never slows down, never leaks memory, and has completely alleviated my need for a native mail client.

My entire family has an account with no ads and I'm absolutely happy to pay for it.

Funny, I did the exact same thing!

Tried to push learning Rust via the Go examples. It has been a great exercise, but highlighted the pain of dealing with various string representations in Rust.

I find it difficult to imagine doing extensive web work (Rails, Django, PHP, JS) without ever touching GitHub.

Surely, in the course of your daily work using giant open source projects you'll file a bug, comment on an issue or even submit a pull request. Most large applications are built off of dozens, or hundreds, of open source libraries—all of which have bugs at various times.

I don't expect all web developers to have side-projects or libraries, but I would expect they'll interact with open source projects in some way. This way of thinking clearly doesn't apply in more closed source worlds like games, finance or giant enterprise—but it certainly holds for startup/web work in my experience.

Latin was required as part of my program in high school, some 20+ years ago now. It wasn't until tonight that I remembered we weren't supposed to read Catullus. Some of the more adventurous guys (all boys school) would make reference to his poems and our highly conservative teacher would have a fit.

Public awareness campaigns were key in stopping the ivory trade within the United States (before it was ramped up again by the Chinese). Demand is the real problem, and creating the image that ivory (or shark fin soup) isn't cool is extremely effective.

There is a fantastic talk by Fred Herbert (of Heroku and Learn You Some Erlang fame) that discusses this exact situation in the Erlang community [0]. Without an accessible ecosystem, useful tooling, a powerful packaging system, or a community sensitive to newcomers what do you have? Erlang is an amazing platform with a community full of very experienced and wisened developers–but elixir widened the appeal.

[0] https://m.youtube.com/watch?v=Z28SDd9bXcE

> Redis recently switched from HyperLogLog to the slightly better LogLog-Beta

Interesting, has anything been written about that? I've learned most of what I know about cardinality estimation from Redis and your writing on the matter, so I'd love to see more. It would be great to re-visit an article I wrote about HLL[0] from a new perspective as well.

[0]: https://blog.codeship.com/counting-distinct-values-with-hype...

You have to applaud him for trying. Building anything as a learning exercise is an investment in yourself, and I'm encouraged when others are ambitious about it.

We've all had "don't roll your own crypto" pounded into us, but nothing teaches a lesson as soundly as trying something yourself. I've tried, failed and learned a lesson from far less ambitions endeavors.

> Ultimately I feel like the use of CI in many open source projects isn't very high due to constant annoyances and difficulty debugging the CI environment.

My perspective may be driven by the communities I'm involved in, but this seems wrong to me. From my experience I would say most open source projects use CI, particularly because so many of the bigger platforms (Travis, Circle, CodeShip) make it free for open source.

It is an extremely valuable resource when you consider the infrastructure and integration you get with absolutely no effort. Installing more obscure libraries or cutting edge releases can be a pain, but it is minuscule compared to the time it would take to provision, secure, and manage a group of containers for an open source project.

The things that have always tripped me up for Erlang are capitalized variables, lowercase modules, and bare word atoms. There certainly isn't anything wrong with those choices, but it is counter to everything I'm used to from other languages that it presents some cognitive overhead.

In the end, even as somebody who cares about the look of code a lot, it doesn't matter to me. The BEAM and OTP are elegant enough to compensate for any syntax.

Many of the great features of modern js (destructuring, fat arrows, splats) came directly from CoffeeScript. As much as I loved the comparative power of CoffeeScript (list comprehensions, everything is an expression), its time has past. There is very little active development and it has lost all momentum. It also never started addressing the biggest issue facing large JS projects, typing and static analysis. Refactoring a CS project is a fragile process that I won't miss.