Hacker Newsnew | past | comments | ask | show | jobs | submit | tumultco's commentslogin

I don't know about "working" but most recently it looks like AlterEgo has gotten closer to a shipping product and did a publicity launch ~a month ago.


Yea, I was hopeful seeing that, but was also pretty skeptical that they really had done it, as that demo was easy to fake, and I saw no 3rd party verification.


To give some more context, Fleming's job was an antibacterial researcher, and also molds were also previously known to have these properties. In some ways, the lucky part was others finding his work and developing it. I found this video on the development of Penicillin a pretty interesting watch:

https://www.youtube.com/watch?v=mhXmkDapHWg


I was curious about this myself. I extracted the json for the "uncompressed" image:

https://gist.github.com/jmfd/8dbb96fcd8a1ba1e8ad6e9167bd70ce...

And then tried these commands against it:

  gzip:        39.56kb    (93.7%)
  zstd:        35.86kb    (94.3%)
  gzip -9:     35.51kb    (94.4%)
  bzip2:       24.35kb    (96.1%)
  zstd -19:    24.01kb    (96.2%)
  brotli:      21.42kb    (96.6%)
(I'm not up-to-date on default web server configs, but I imagine most would automatically transmit with gzip over the wire for json?)


JSON compresses well in general. Can you do the same with a binary version?


I only have the "final" 13.5kb version to test against. It compresses very well:

  gzip:     6.95kb    (98.9%)
  brotli:   5.99kb    (99.0%)


Man, I should have done this — would've been a much nicer number for the headline. Thanks for the analysis, though, this is really cool!


I compared it to image in PNG and QOI formats [0]

    img:         13.552kb (100%)
    img.png:      1.877kb (13.8%)
    img.qoi:     10.316kb (76.1%)
    img.qoi.gz:   1.167kb (8.6%)
While it does compress by 50%, it's not a format optimized for compression unlike png or qoi

[0]: https://qoiformat.org/


Given equivalent data stored in both JSON and BSON format I would expect them both to compress down to blobs of roughly equivalent sizes. This is because both encode roughly the same amount of information, so the compression algorithm will tend to compress down to the same final result. I haven't run this as an experiment though..that would be fun.


Is it faster though?


Context is the rest of the sentence:

> and polish on the app for free forever

But even "bug fixes" are sometimes not cleaning up your own issues; for example, macOS updates regularly will break apps. It's like paying someone to lay down a lawn for you and expecting the grass will never need cutting.


> It also feels super shitty to launch 1.0 out of the blue AND then expire the public beta builds that we have been using for 3 years with 4 days notice...

The 1.0 has a 14 day trial, so that at least extends it to 18 days notice.

It really seems like the beta program might have been a victim of its own success (and ridiculously long duration).

It is interesting to look at it through the lens of what's the social contract between a beta user and a developer? I feel the basics are that users get access to features ahead of time in exchange for reporting bugs if they discover any, but nowadays perhaps folks think there should be more they get out of it? Of course it isn't fun to beta a pre-1.0 product and have the workflow disturbed because the price isn't palatable, but that's the risk?


> It is interesting to look at it through the lens of what's the social contract between a beta user and a developer?

I think that social contract can be anything you want as long as you communicate it clearly and in advance (they did neither).

---

What "beta" means and its timeline varies widely. Mimestream was technically in public beta this whole time but quality-wise has been production-grade software most of that time. Gmail was in public "beta" for 5+ years.

Of course, many apps hit 1.0 eventually... but then a lot of those migrate their beta program to TestFlight to continue to help fix bugs and as a thank you for helping get the software to 1.0.

But the most important things if you do decide to kill the beta track post-1.0 (i.e., take away features from your users) are to: (1) give your users a timeline and sufficient heads up in advance (e.g., 30–60+ days), and (2) solicit feedback from and listen to your users. If Mimestream had done either of those, this launch would have gone a lot better.

Mimestream also offered beta testers a first-year discount code, which seemed like a nice gesture. But then upon reading the press release, they offered everyone basically the same discount. So that cheapened the offer and made the connotation go from "they're thanking their beta testers" to "they're just trying to convert as many people as possible".


If you're on a retina display, I recommend adding this CSS so it uses nearest-neighbor interpolation for the scaling:

  img {
    image-rendering: pixelated !important;
  }


I would suggest adding that as a HTML style for each 88x31, rather than making every image on a webpage pixelated.


Thanks for your work in developing this!

Does Lexical have a feature to set arbitrary CSS on a particular selection range? I've been looking for a solution to do this since the WebKit's -[WebView applyStyle:] is deprecated as part of WebView Legacy. It isn't clear to me from glancing at the docs if RangeSelection.formatText() or other methods can handle anything or just a subset of styling code. Thanks!


Yes, we have something like this in @lexical/selection: https://github.com/facebook/lexical/blob/af099ffd9f464b523d6...


Just mentioning SlateJS which has [decorations](https://docs.slatejs.org/concepts/09-rendering#decorations) for this


It wasn't in the above list, but Apple did completely remove PHP in Monterey.


I made a revised icon that imho fits in better with the Big Sur's look and works at Dock sizes:

https://twitter.com/jmfd/status/1417595485653635073


I'd say the difference in HyperCard and Visual Basic is that they also define their runtime environment. The IDE can grow with the runtime. Writing tooling against a vast runtime like the web is much more difficult and daunting.

A 1.0 would need to address a large enough surface area of the web to be useful. There's also a discordance between hand-coding "friendly" HTML/CSS and what would be exposed in a WYSIWYG tool. Further complications are all the new and old bugs in browsers.

That said, every day I was working on Hype 1.0 in early 2011, I would nervously check Hacker News for a "Show HN" post for a HTML5 animation app that would steal the thunder; luckily none came. This is even more surprising given Hype exports were mostly compatible with Internet Explorer 6 -- such an app could have been written long ago.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: