Transform SVG into React components - <AUTHOR> https://github.com/smooth-code/svgr <comment><USER2> This is doing little more than providing a wrapper around svgo, which is doing all the real work.

This is generally a poor use of SVG as well, if your use of SVG is for static assets, don't transform all your SVG into react, leave it as SVG where it can be easily manipulated and editing by the plethora of tools that can work directly with SVG, previewed in the browser, etc. If you need you can inline the SVG into your CSS via a base64 URI, etc.

<comment><USER3> I love adding my svg as react components, actually. It makes it easy to conditionally toggle parts of it, change text, manage colors, etc.

Of course, if you just want to use the svg doc as a static icon, then yes by all mean, a plain file will do. But given the (very small) size of a svg file, caching it as a single resource may not be that useful.

<comment><USER2> Umm, you should be doing that with CSS. Basically what this means is whenever your application code changes, it busts the cache on all your SVG assets if you use this method.

The only use-case for using SVG with something like react is for data visualization where you are programmatically building up and updating a SVG DOM based on some data.

A good example of this is a flow-chart graph/tree UI done in SVG that is generated from a nested data structure. Its unlikely these elements would be expressed as static assets in the first place.

Even still I would be cautious in using SVG in this way for all but the least trivial things, as react has been optimized to diff HTML structures, not SVG. I'd like to see, for example, how it handles SVG cascade transforms for instance. Its usually not efficient to alter the SVG DOM by inserting/removing nodes, because the layout rules and semantics of SVG is different than HTML.

</comment></comment></comment><comment><USER4> Let's not forget, sometimes when you need some really basic functionality, you don't _have_ to reach for a module that maybe does a lot more than what you need. For example, the last time I needed svg inlined into a web app I was working on, this is the quick component that I whipped up:

[https://gist.github.com/ajbdev/8d15e302564fe04a7d383c1a54f8d...](https://gist.github.com/ajbdev/8d15e302564fe04a7d383c1a54f8d97d)

Despite it's simplicity, it has yet to fail me.

<comment><USER5> besides - if you generate your SVG programmatically you can just return them in your render function:

function Foo(props) { return <svg> <circle cx="10" cy="10" r="100" /> </svg> }

</comment></comment><comment><USER6> This does exactly what I have been doing manually for at least ~15 times in the last week. If only I saw this a few weeks ago.. (It's easy / not lot of work, but why if we can automate?)

</comment><comment><USER7> Doesn't `react-svg-loader`[0] do the same?

[0] [https://github.com/boopathi/react-svg- loader](https://github.com/boopathi/react-svg-loader)

<comment><USER8> I'd done this awhile ago with [https://github.com/ryanmcgrath/react- iconpack](https://github.com/ryanmcgrath/react-iconpack) (haven't touched it in literally forever, at least insofar as time is considered in the JavaScript world - probably doesn't work now), too. Never caught on for whatever reason, but was fun to hack together.

I do feel like (and I think another commenter somewhere in here noted this) that actually fully converting SVGs to JS has a lot of detriments in terms of ability to edit and such, so the loader approach is better.

<comment><USER7> Another approach which I use at work is to use `postcss-inline-svg`[0]. This allows you to "import' the SVG from your CSS and then customize it. For example, you might want the icon in a different color:

        background: svg-load('myicon.svg', fill=blue);

The SVG would then be inlined into the CSS instead of the HTML.

[0] [https://github.com/TrySound/postcss-inline- svg](https://github.com/TrySound/postcss-inline-svg)

</comment></comment></comment><comment><USER9> "Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."

</comment><comment><USER10> Super cool to see other people using this pattern! People here are bringing up great points about the implications of this pattern. Our motivation to use this pattern was when replacing grunticon generating multiple colors of our SVGs during a build step. The grunticon step added a 1min+ to the feedback loop on seeing CSS changes(could have fixed this directly, lots of missed details in this story).

This simple script allowed us to quickly move past the problem during a rewrite to React, and solve more correctly when that system was a priority. [https://gitlab.com/gjjones/svg-to-react](https://gitlab.com/gjjones/svg-to- react)

</comment><comment><USER11> If I can have only one question, it would no doubt be "why"?

<comment><USER12> We do this at my work - it allows easy programmatic inclusion.

We wouldn't do it if browsers weren't a buggy mess with the USE tag though (Chrome in particular is a dumpster fire of SVG bugs).

<comment><USER13> Yeah, USE tag is pretty buggy across browsers.

Also, sometime you just need to inline SVG, for example if you want some icon path fill color to change on mouse-over. Easy with inline SVG and CSS rule. Can't really do that (well) with external .svg.

<comment><USER12> We actually had a nice system for that... but again: browser bugs :(

Until browsers collectively get off their asses with SVG (most of these bugs are _years_ old in their big trackers) using React for SVGs is a good workaround.

<comment><USER14> They won't because it seems like they might as well forge ahead with CSS additions and drop an entirely separate renderer. That's what happened to the SVG Animations.

Of course it's not like svg will get removed so Why fight it...

<comment><USER12> It seems they stop work as soon as a feature hits SVG - CSS Animation, Canvas, WebGL... all have open SVG bugs. Some years old.

</comment></comment></comment></comment></comment></comment><comment><USER15> Amazing.

<comment><USER16> HN is really aware of these type of comments. An account created 47 minutes ago. A single comment on this post.</comment></comment>


How I started programming - <AUTHOR> https://blog.steve.fi/how_i_started_programming.html <comment><USER2> I played with QBasic when I was young but never got into "real" programming until college, I wonder if I'd be more than a mediocre programmer today had I been exposed to assembly, which I ended up liking as a class but never did for fun.

But computer games as a gateway drug to programming is familiar. I had no idea what the hell EMS (Expanded Memory System) and XMS (Extended Memory System) were. But I managed to get Ultima VII and its apparently bizarre memory manager [0] to work on my computer. I now realize I was clueless about how the Windows OS worked, or basic principles of the command-line, but at least I wasn't afraid of it. Or with editing random INI files. Experimenting with INI files and booting into DOS was the only way to get U7 to run on Windows 95 systems.

[0] [http://wiki.ultimacodex.com/wiki/Voodoo_Memory_Manager](http://wiki.ultimacodex.com/wiki/Voodoo_Memory_Manager)

<comment><AUTHOR> I had a huge gap, between playing with the Spectrum in the early eighties to using a PC for the first time around 1992.

I remember using QBasic, and using debug.com to write simple assembly programs - the most memorable one was a simple utility to "undelete" files from MS-DOS, which just involved modifying the FAT.

Most of my memories of the early PC-days were reading Ralph Brown's interrupt list and looking at the source code of viruses, via magazines such as 40HEX.

</comment></comment><comment><USER3> I also started on ZX Spectrum. The interesting thing was, unlike PCs, which continuously improved, the hardware of ZX was pretty much fixed, so people had to come up with more and more ingenious ways to optimize.

I recently downloaded and opened the "BASIC Reference Guide", and I was surprised. All the different BASIC commands that I considered quite complicated when I was 11 had full description on couple of pages. It was nothing compared to today languages' APIs!

</comment><comment><USER4> Brilliant! This brought some old feelings come flooding back - especially the link to those Usbourne books, I'd forgotten about them, I definitely had a couple of those.

The author's experience pretty much matches my own formative experience with a ZX Spectrum, from Basic to Z80 Machine Code. But then I kind of stopped and did other stuff for a few years. Now I'm a front-end dev for my sins. BASIC and Z80 Assembler is much much simpler than all the crazy abstractions one works with these days!

<comment><AUTHOR> I never owned any of those books myself, but when seeing the covers I immediately recognized some of them.

(Largely because I'd checked them out of the local library so frequently.)

<comment><USER4> I think I had the space games one. I remember keying in the moonlander game. What I found interesting was the feelings it stirred in me. I 'remembered' in an emotional way what it was like to be 10 years old and keying in BASIC programs from books and magazines.

One of the other things I remember doing was drawing a pattern of lines radiating out from the centre of the screen. The spacing between the lines would interfere with the video rendering and you'd get lovely moire patterns. Varying the space between the lines would change the pattern.

</comment></comment></comment><comment><USER5> Steve, just brilliant! Like a lot of others will surely say, thanks for taking us all back for a brief moment. Your post has inspired me to write a similar one on my own site.

It would be pretty cool if there were a website dedicated to the tales of how individual developers got their own start and the memories that they have of how magical it all seemed way back when. I bet there would be a lot of overlap in the stories regardless of the era.

<comment><AUTHOR> I'm sure you're right about overlap; I know that the Spectrum was probably the best-selling machine in the UK at the time, so there must be thousands of people who starting programming as a direct result of owning one.

There are whole scenes I'm utterly unaware of, like the Atari vs Amiga thing that I remember reading about at the time but paid no attention to. I'll pretend those users were more at home with the PC!

<comment><USER5> Actually I started on an Atari 400 and then eventually an Amiga 1000. Perhaps that's more common here in the states?

</comment></comment></comment><comment><USER6> Similar for me really. All my school friends had spectrums, i had an Acorn Electron. Nothing wrong with it at all, but i had no one to swap games with...and being poor led me to messing about with the code side of it. Well done to my parents for not listening to my cries for a different machine...future me appreciates it.

</comment><comment><USER7> Another nice thing about the ZX Spectrum was that it had all the basic commands printed on the keyboard. Great for experimentation as a kid.</comment>


If NSA Can Hack WiFi 8 Miles Out – Implications for Commercial Use - <AUTHOR> https://www.ubergizmo.com/2013/12/the-nsa-has-a-device-that-supposed-can-hack-your-wifi-from-8-miles-away/
Assume that the NSA, as they claim, can hack wifi 8 mile out. Then it must be possible for a network of enhanced wifi routers to act as a wide-area network similar to now-defunct Metricom's Ricochet system except far more robust, distributed and less costly. Such a network, by reducing the role of local ISPs, could reduce unwanted monitoring (by NSA and others).
I am asking for suggestions about software/hardware enhanced stacks for such a "New and Freer Internet"? <comment><USER2> 8 miles away, if cities, now that would be impressive beyond belief. 8 miles away, small town on the side of a hill, sure.

Though a drone 8 miles up, would we see or hear that?

Also are the NSA as curtailed about legal transmit power as as mear citizens? As being able to boost transmit power, yes 8 miles reasonably focused and drowning out everybody else, would not be subtle.

Now when they can do it with low-orbit satellites, an array of those beamforming - oh it maybe fantasy, but gets me onto one safeguard.

Should wifi have radio latency checks? By that, ringfence via radio latency how far away somebody can connect - even if they can see or transmit from 8 miles away, if you had protection that ignored anything over 20 meters away, you would totally be able to lock those connections down. That would need to be at chipset level, though with a good resolution ping, you could augment security and with a more granular ping, would be able to tell how far away any connected wifi device is. So technically possible with hardware already and just a software feature that could be added and remove anybody over a certain distance from even holding a connection upon the network over wifi.

<comment><USER3> > _Now when they can do it with low-orbit satellites ..._

Some of the better speculation I've come across suggests American ELINT satellites have deployed antenna spans measuring _hundreds of feet_.

That might explain why grabbing cellular transmissions right out of the air without requiring terrestrial resources has been a thing for at least a couple decades now.

When you have virtually unlimited budget, you can do a lot of things thought previously impossible.

</comment></comment><comment><USER4> If you have the correct antennas and possibly amplifiers on both ends you can established a Wifi link over hundreds of miles (if you have line of sight). Basically, if you can see the other device you want to communicate with at building level with your eyes then it's not too difficult to establish a Wifi link with it using off the shelf parts.

On the other hand, intercepting a 'normal' Wifi signal (e.g. me browsing HN at home using omni antennas and standard Tx power) from 8 miles away is quite a feat and I doubt that they can do that at will. Probably only in specific scenarios (e.g. line of sight in a not too noisy environment), if at all.

<comment><USER5> > If you have the correct antennas and possibly amplifiers on both ends you > can established a Wifi link over hundreds of miles (if you have line of > sight). Basically, if you can see the other device you want to communicate > with at building level with your eyes then it's not too difficult to > establish a Wifi link with it using off the shelf parts.

Any resources you can share to do this?

<comment><USER6> I can't speak to hundreds of miles, but I built a Wifi bridge that went about 1.75 miles across a cow pasture with center-pivot sprinklers using a pair of WRT-54G routers, DD-WRT, and some yagi/panel antennas from Amazon about 10 years ago. Total price was under $300 and speeds of 11mb were all we went for as it was just feeding a PC for browsing and time-card punches in a shop across the pasture from the office.

It ran happily for nearly 6 years before being replaced with a packaged kit of antennas and POE injectors that advertised 54mb over 2-3 miles seamlessly for around the same price.

If you had a pile of old 802.11b gear and the time and gumption, I'd think you could build something like this for sub-$50 at this point.

</comment></comment></comment><comment><USER7> I think with all technical things there's a lot of context we don't know.

I don't doubt it could be done in some specific situations ... not so much 8 miles in other situations.

No doubt a contractor or someone would be happy to take the development money for '8 miles' ;)

</comment><comment><USER8> I don't know about 8 miles, but you can greatly extend your WiFi range with an external WiFi antenna and a large dish.

</comment><comment><USER9> Depends on how many people are micro-waving (at 2.4 GHz) their supper at the time.</comment>


Dairy-rich diet linked to lower risks of diabetes and high blood pressure - <AUTHOR> https://www.eurekalert.org/pub_releases/2020-05/b-ddl051420.php <comment><USER2> Link just means correlation. Correlations are easy to find and don't mean much.

They don't explain _why_ and _how_ dairy would help reduce risks of diabetes and high blood pressure. So they're not doing science.

Note how they say:

> This is an observational study, and as such can't establish cause.

It's not like you could ever _establish_ a cause anyway. Causes are explanations and they are conjectural in nature. They could have just guessed that dairy helps reduce those risks and then try to explain why. That data from all those different countries could then maybe be used to refute that explanation. But the explanation should come first.</comment>


Show HN: A snapshot of the active processes in your system - <AUTHOR>

This is a small perl program that I wrote to draw the active processes in a GNU system. You can see it in:
http://pvaldes.esdebian.org/49625/mapa-procesos-sistema-ii
Text is in spanish, but you don't really need it to grasp the idea. Just take a look at the figures or, if you want, play a little with the code. Before to use it you will need to have installed graphviz and libgetopt-long-descriptive-perl
This can be used to 1) play and learn about how programs interact in a gnu system, 2) discover the programs that are "memory eaters" and 3) be able to take quick snapshots of your system and save it in several pdfs if the computer starts to go slow for any reason.
Of course you will only be able to drawn the processes that you own. As root you can see the whole thing. <comment><USER2> Posts without URLs are penalized, so you'd be better off posting this as a link to your site and then including the text as a comment in the thread.

<comment><AUTHOR> Well, in fact first I filled title, url and text: error message from HN ("sorry you can not have both title and url in the same post"). Ok, Then I deleted the title and put just the url and text before to re-send, having two error messages more ("try to send the post again" or so...), finally with title and url in text the post was accepted by HN... I don't know why.

<comment><USER2> You have to have a title, and one of url or text (but not both).

What I'm saying is that title+url would be a better choice for your post than title+text. You can add your text as a comment to the thread after the submission has gone through.

<comment><AUTHOR> mmmh... I didn't know it. Understood, thanks.

It seems that I can't change or delete the post now. Sorry for any inconvenience caused.

<comment><USER2> You're welcome to repost it the way I suggested. Good luck!</comment></comment></comment></comment></comment>


"This resentment runs deep and is stunningly widespread" - <AUTHOR> https://daringfireball.net/linked/2020/06/19/swisher-app-store-hey <comment><USER2> The CEO of Basecamp posted a response to all of this on they Hey website that I found to be an interesting take that I hadn't seen talked about elsewhere.

An all too brief summary is that customers coming in through the App Store are not your customers - they're Apple's, and you lose the ability to support them. That falls on Apple, and Apple will inevitably fall short of expectations.

Most recently, I spent several years at a subscription-based company. The size of their customer support dwarfed technology, operations (the company ships physical goods), and even sales. And without the 1,000+ hours/week of work by customer support, the company would have seen so much churn to have long ago been out of business. Yes, it would be great to have a situation where everything works perfectly, no customer ever has a problem (even when those problems are well outside of your control), and are 110% happy... but that's just not a reality for many companies.

[https://hey.com/apple/iap/](https://hey.com/apple/iap/)

<comment> ezequiel-garzon Thanks for your comment and the link. If I understand correctly Hey tried _not_ to include IAP in their app, so customers would need to make all transactions on their website, right? If that's the case the rules are beyond arbitrary, since e.g. Amazon's Kindle app doesn't allow you to buy books through IAP (I'm assuming to avoid that 30% cut), and still Apple approved the app. Am I missing something?

<comment><USER3> "Reader" apps (consume content) versus utility/creator apps.

Apple concedes not taking a cut of your content subscription (Netflix, Kindle, magazine readers, etc.), but if someone is subscribing to your app as a tool (not to the content), Apple feels justified in charging for the tool's ecosystem.

<comment> ezequiel-garzon Thanks for your clarification, I didn't know that.

</comment></comment></comment></comment><comment><USER4> The App Store has always struck me as an example of Joel's 'commoditize your complements' strategy.[0]

 _Once again: demand for a product increases when the price of its complements decreases. In general, a company's strategic interest is going to be to get the price of their complements as low as possible. The lowest theoretically sustainable price would be the "commodity price" — the price that arises when you have a bunch of competitors offering indistinguishable goods._

Thus: $0.99 apps.

If you're feeling resentment, it's because you've been thoroughly commoditized to increase the perceived value of Apple's hardware.

(Of course it's somewhat false "value" \- infinite shovelware is worth about what it costs.)

[https://www.joelonsoftware.com/2002/06/12/strategy- letter-v/](https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/)

<comment><USER5> What surprises me is that Apple does not make a distinction between commercial developers and open source developers, or any others that make only free apps. Both need to pay almost 100 bucks a year just to have the opportunity of publishing on the app store.

It seems to me that in the vein of 'commoditize your complements', developers that only publish zero cost apps shouldn't pay an annual fee for the privilege of making Apple's ecosystem more valuable.

</comment></comment><comment><USER6> "the business model policies of the App Store have resulted in a tremendous amount of resentment. This spans the entire gamut from one-person indies all the way up to the handful of large corporations that can be considered Apple's peers or near-peers."

Exactly on point. It is time for change.

<comment><USER7> I will say this is a surprisingly powerful comment from gruber, who has generally been extremely forgiving of apple.

<comment><USER8> Perhaps there are fractions at Apple wanting to change this, and Gruber has sided with them...

</comment></comment></comment><comment><USER9> I get a lot of requests for small, quick apps from researchers who want to display a little content, maybe a form submission, sometimes a QR reader or something.

I am always stuck saying "we can have the Android version out in $days, and the iOS app sometime between a week later and never."

It's an upsetting thing to say but there's just too much risk dealing with them for projects with tight timelines/budgets.

<comment><USER10> Related question: Why are people making entire apps for things which sound like they should be webpages? Only the QR reader sounds like something that needs to be an app, and there are 100s of QR reader apps already, and some phones have it integrated natively in their OS.

<comment><USER9> You're not wrong, and beyond web pages some of these things could be PDFs or text files even.

My perspective is, if I'm not doing anything evil, why do I have to clear a complexity bar to publish an app? There are also some advantages for simple apps, one is making it really easy to use offline with a nice shortcut on the home screen. The other thing is making it full screen and no address bar helping to decrease distraction.

These are not amazing reasons, but they matter for some people.

<comment><USER10> I am definitely not blaming you. It just feels that we have reached this bizarre state of affairs where we create so much useless cruft for vaguely articulated reasons which are often not even true or borne in strong data, but are rather some abstract intuition of some marketing folks somewhere who are probably cargo-culting what they heard from another bunch of marketing folks.

</comment></comment></comment></comment><comment><USER11> _acknowledgement of all the undeniably great things about the App Store from the perspective of users and developers_

As a user, I shudder anytime I have to interact with the App Store. Even when it works flawlessly, there is nothing interesting or pleasing about it. And most of my interactions with it leave me with a mild feeling of having being bullied about.

I had much rather install software via Homebrew than the App Store.

<comment><USER12> What specific interactions make you feel this way?

<comment><USER13> I'm a software developer myself. For me, its more like a disengagement from the whole thing.

Do you remember when android/ios were new and there were all new and fun games coming out like angry birds and such? Everyone was into it for a couple years.

Now, if you look at those same games (or even apps from the same era), every single thing about them is made to suck money out of you. It just does something to you, and I've noticed this in most people I know too, it just makes you sick.

Rather than constantly worrying about how not to be a sucker when searching for a new app, I now frequently decide that whatever it was that I wanted to do, I could do some other way or not do at all rather than be subjected to the constant victimization by aggressive monetization everywhere you look.

The hard truth that we, the tech industry, are currently not accepting, is that the value of a lot of the software out there, is actually zero or close to it. The industry has matured. Commoditization is imminent.

Software will be like auto, energy, medicine. Just another industry. Software developers will be like plumbers, advertisers, electricians - It'll be just another trade, but the past gold rush and the remaining few nuggets still out there will blind us all to this fact for the next decade at least.

<comment><USER14> Some anecdata on this point; I've tried two times to find a decent solitaire app on the app store. I don't play solitaire that often, it helps to pass the time occasionally, so I don't need something particularly complex or featureful.

Every app I could find had some dark pattern or an overflow of ads or both. Some kind of streak system where you were encouraged / nagged to play every day or else lose your "coins" (aka preying on loss aversion to try and addict players), fullscreen interstitial ad pages that try to trick you into clicking them when you're moving cards? Animated banners that distract you from the game?

I ended up giving up and just using a web version. It's not perfect, it's made for desktop and the cards are really small on my iphone 6 and the UI is hard to use, but it's clearly someone's labor of love and a lot pf care has been put into it. I'd happily pay a few dollars for it, if it wasn't free.

There's not many apps like that on the App Store nowadays. And with Apple's predatory rent-seeking practices, requirements of owning a $2000 computer to develop for their platform, and high developer fees, they aren't helping the situation.

<comment><USER15> I haven't dug deep on this, but I bet the following URL will offer some helpful ideas:

[https://www.google.com/search?q=ios%20solitaire%20reddit](https://www.google.com/search?q=ios%20solitaire%20reddit)

Here is the best looking one from the first thread Google returned for me:

[https://apps.apple.com/us/app/solitaire-decked-out-ad- free/i...](https://apps.apple.com/us/app/solitaire-decked-out-ad- free/id1153389718)

<comment><USER14> Thanks, it's ok, no ads, but it has coins and lootboxes and daily rewards, so still far from ideal. I understand developers gotta eat but it's still frustrating.

</comment></comment></comment></comment></comment></comment><comment><USER16> > I think if Apple measured developer satisfaction scores on the App Store, > the results would be jarring.

I think their ARM Macbooks have the opportunity to be a real tipping point if they make macOS as restrictive as iOS. Who'd sign up for another decade of this? The only argument I've seen for them to not do that is a wide range of developer tooling won't work, but perhaps they're OK with developers exclusively using their own languages. They actually did ban apps made in Flash (the IDE), Unity3d and other cross-compiling technologies from iOS for a while even though they were producing native apps, and more recently they banned apps using Electron too.

[https://daringfireball.net/2010/04/iphone_agreement_bans_fla...](https://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler)

[https://venturebeat.com/2010/09/09/apple-loses-game-of- chick...](https://venturebeat.com/2010/09/09/apple-loses-game-of-chicken- allows-flash-and-other-conversion-tools-for-ios-apps/)

[https://9to5mac.com/2019/11/04/electron-app- rejections/](https://9to5mac.com/2019/11/04/electron-app-rejections/)

<comment><AUTHOR> I think it's safe to say the CPU architecture of the Mac is orthogonal to future restrictions Apple may put in place on MacOS (other than at the EFI level). Not to say that they _won't_ make the mistake of locking down MacOS to an iOS level in the future, but x86 has never inhibited nor does ARM specifically enable such a move for the OS.

<comment><USER17> Plus moving desktops/laptops to ARM would require a giant effort of developer opt-in and monetary investment industry wide. I don't think company experience with mobile/tablets via the App Store is a sufficient example of buy-in to say it will be a viable choice.

There's a ton of random MacOS software that would need to be ported, upgraded, or virtualized which could take a full decade to really cover the full ~99%, with the last 1%+ mostly dying off.

Apple usually doesn't like running two product lines with arm/x86 options, so it would probably be some weird transition thing.

<comment><USER18> > ...would require a giant effort of developer opt-in...

I'm not sure how true that is, there are a ton of workflows that can run solely on iPads. The problem is largely physical form factor and a little bit of UX smoothing for desktop computing on bigger screens.

I don't see it as a forgone conclusion that ARM Macs need to bring over the legacy software, why can't they just use what's present in iOS? If I want to design a form, I care less about the name on the app than I do about how well it works.

I think a lot of desktop MacOS developers are in for a very rude awakening about how irreplaceable their apps really are.

</comment></comment></comment></comment><comment><USER19> Once upon a time the idea of a computer was that it is a universal machine that can do any computation for you. As soon as the people producing the computer are the same people controlling what software can run on it this idea is out of the window. An app store is an evil idea right from the start. Unless you actually don't want to own a computer but just want to buy a toy, of course. Which is the bigger part of the market. It is the task of us software developers who should be able to understand this to push hard against the whole idea of an app store.

<comment><USER18> This line of thinking is as selfish as it is revisionist. Computers were not intended to be a playground for the high priesthood of initiates with Very Important Computations, they were intended to be tools to accomplish tasks. I think it's insane to throw out the incredible democratizing effect app stores have for the overwhelming majority of society in the name of you having perfect control.

App Stores have done a huge good for society in bringing capability to the general public. If a few startups have to suffer for it, oh well, that's their job. It's not an accident the degree to which smartphone sales outstrip feature phone and traditional computer sales.

This leaves out the discoverability argument, good luck getting people on the internet to find and install your random app. Then there's the security argument. Would you feel safer downloading a random script from the internet and piping it to bash, or a random ipa from the app store?

<comment><USER20> Computers started as million dollar machines back when Coke was 10 cents, that only very smart people who could think in machine code were allowed to touch.

Perhaps at the minicomputer level did they start to enter the realm of more basic tools rather than being massively expensive infrastructure. You could call the massive caterpillar that moved the Saturn V to the launchpad a "tool" technically, but not really.

<comment><USER18> I never said basic, you added that to change the meaning to what you want it to be. CNC routers are often described as "the right tool for the job" by machinists, and they can run into the millions.

These magic boxes were always designed to solve specific problems. That's the generally used English meaning of tool. In my experience, people largely object to the word tool because they don't think it sounds important enough. Too bad for those people that it fits so well.

</comment></comment></comment></comment><comment><USER21> The question now is what are the functions of App Store. Search and purchase convenience? I guess so - but that is easy to replace and substitute. The real one is security vetting. We see more and more problems in this area (with back doors injected in Open Source libraries, which maybe was just the visible part, because similar attacks would be much more stealthy in closed source). So it is more and more important. Can it be replaced? I don't have much expertise in this - but it seems to be very deeply intertwined with the operating system.

I like to use the Christensen/Ben Thompson framework of integrated and modularized systems: [https://stratechery.com/2020/chips-and- geopolitics/](https://stratechery.com/2020/chips-and-geopolitics/). But how that appliess here? Phone is a 'good enough' product now - so it should be modularized. But how can you do security in modularized way, how security could be separated from the OS? Maybe we need more vm based sandboxes ala QubesOS?

</comment><comment><USER22> Microsoft attract developers who attract users.

Apple attract users who attract developers.

<comment><USER23> There is truth to this and it runs deep in the DNA of the two companies.

On stage years ago [1] [2] Bill Gates and Steve Jobs were asked what they wish they had learned sooner that the other guy did first. Gates ventured that he would give a lot to have Steve's taste. Jobs responded that he wish he were as good as Bill at partnering with others.

These were more than off-the-cuff compliments. They speak to Apple's DNA as a design company focused on UX, and Microsoft's DNA as a platforms company.

[1]: [https://www.wsj.com/video/bill-gates-and-steve-jobs- at-d5-fu...](https://www.wsj.com/video/bill-gates-and-steve-jobs-at-d5-full- session/60C4F9FA-9AD5-4D04-8BB6-015AEBB1C052.html)

[2]: [http://allthingsd.com/20070531/d5-gates-jobs- transcript/](http://allthingsd.com/20070531/d5-gates-jobs-transcript/)

</comment></comment><comment><USER24> I definitely concur. We've been making an open-source MUD client for a decade, all for free, on our time. We have to pay $99USD for the privilege of giving it away for free to macOS users. It's ridiculous.

We get no value in return for that $99USD - absolutely zero.

</comment><comment><USER25> > they fear speaking out publicly

Are there cases where Apple has retaliated against developers that do speak out publicly? Or is the reticence to go public because they know that any chance of special treatment is worth keeping silent?

edit: publicly not privately

<comment><USER26> > _Are there cases where Apple has retaliated against developers that do speak > out privately?_

Do you mean publicly?

How would you determine if a developer was retaliated because they spoke out? I don't think Apple would ever issue a press release saying "yeah, we banned developer X from our platform because we didn't like his New York Times interview."

The thing with Apple is, app store rules are vague and arbitrary, and Apple is the judge, jury, and executioner. They interpret and apply the rules inconsistently. They have utmost plausible deniability. How would you prove that you were removed, not for violating a vague rule that thousands of other apps violate in the same way, but for speaking out?

Even if someone thinks about raising a stink after getting banned, they probably won't go through with it. As we have seen on HN, Apple is so well loved that when a developer speaks out against Apple, most people side with Apple and attribute the developers complaints to not following rules, sour grapes, greed, hating users, etc.

<comment><USER25> (Right, publicly)

I suppose developers are most likely to speak up when Apple has applied the rejection. And that is when you want a lifeline the most -- public shaming doesn't necessarily help your friendly HN-reading Apple employee to reach out and make a case.

The App store rules don't seem that vague -- just draconian. Sure, 30% of a paid app. IAP through a nice end-to-end Apple experience, where consumers don't have to enter any new information, are 30%? Make sense.

Can't offer IAP yourself? I can go either way, but to me this is the line where Apple is turning the screws. Boy do they turn them. Can't offer subscriptions outside the app. Can't link to other options for payment. Can't have a front end to a SaaS app that is primarily used on other platforms. Can't even mention the fact that Apple is taking a cut.

The app store rules do seem somewhat arbitrarily enforced. Ok, your 1.0 goes in but a critical bugfix? Now we shake you down.

If I were affected by this, especially for a subscription app I'd be contacting other affected parties and trying to educate the public on exactly why their subscriptions cost $14.28 instead of $9.99

Through Google SEO, of course, instead of inside the app, because Apple restricts what you say in the app about app store pricing.

<comment><USER14> the rules aren't so much vague as inconsistently applied: for example, the Fastmail app works exactly the same as Hey, and hasn't been removed (yet, at least). More: [https://youdownloadtheappanditdoesntwork.com/](https://youdownloadtheappanditdoesntwork.com/)

</comment></comment></comment></comment><comment><USER27> This is the sort of thing which suggests to antitrust enforcers what to cut out of a company to reduce its monopoly power. Apple could be forced to sell off their "app store".

</comment><comment><USER28> So what is preventing some other company to build and manage an app store for Apple software?

If Apple is preventing competing app stores, isn't that anti-competitive?

<comment><USER29> The argument is that iOS is not a monopoly because there are other smartphone ecosystems.

I'm of the opinion that Android and iPhone are not interchangeable. They have different experiences, and there are things that are mutually exclusive by design (iMessage, Notes, etc.)

<comment><USER30> The economic concept of substitutes does not required the products to be indistinguishable. They are clearly competing devices under any definition.

</comment></comment></comment><comment><USER7> I think customers and developers deserve more from apple.

what happened to the firewall apps? One by one they were banned. (As a customer, I would LOVE to install a firewall like Little Snitch or better)

even better would be to run my own icloud. That would be better from a privacy standpoint (its a right!) Keep your kids safe, keep their data at home!

<comment><USER31> Not just banned exactly. As I follow it, APIs used to create network plugins were restricted to the point where it wasn't clear how Apple wanted such apps to work. Or rather, it was clear Apple felt their built-in tools would be enough. For some, sure. And yes, reducing functionality is a legitimate way to make a system more secure. But— it also does, you know, reduce functionality...

<comment><USER7> I still run an old not-updated version of Adblock ([https://adblockios.com](https://adblockios.com)) that created a vpn at 127.0.0.1 and would block specific traffic.

Then apple changed the rules and now it appears to be a crippled safari "content blocker".

</comment></comment></comment><comment><USER32> Seen a lot of comments to the effect that 30% is not a lot.

But what about corporate taxes, what about things like the game engine getting a cut (often an additional 5%), etc?

Apple Developers end up getting a slice of a slice.

That 30% is large enough to make whole business models unviable. You need 30% more sales or raise prices commensurately. That's a lot.

You'll probably have to spend more on customer acquisition to achieve those numbers as well as you start to eat into the long tail of customers. This eats into profits.

The cut probably also impacts the quality of experience, particularly for things like freemium games, as you need to monetize more aggressively to make up for the Apple tax.

</comment><comment><USER33> There is a need for servant-leader(s) who can build upon the example of RMS, and spearhead a parallel organization to the FSF that can

\- square the circle of using Free Software with

\- the gnarly aspects of running a business and

\- deliver competent, secure products for the modern day.

Maybe there are some ethical vendors out there, but they haven't got the advertising budgets of the Fat Cats, so help my ignorance in the replies, please.

<comment><USER34> Did you mean to post on a different thread?

<comment><USER35> The best parts of the life work of RMS are related to the understanding that Liberty can only be achieved if the means of discourse and use of language generally are free and open to all. Without free general computers and the free access to learn from and build upon the works created by those who came before us, we have no collective shoulders of giants to stand upon and continue the advancement and change of society.

[https://en.wikipedia.org/wiki/The_Right_to_Read](https://en.wikipedia.org/wiki/The_Right_to_Read)

<comment><USER18> And yet a truly stupendous amount of meaningful, useful work is done using evil, proprietary, closed-source Windows every day. How can this be??

This story does a great job of fear mongering, but that's about all it's good for.

<comment><USER36> Because on windows you are close enough to free. Raging twitter mob cannot force microsoft to prevent windows from working on your PC, you can install any app without microsoft approval etc etc ...

</comment></comment></comment></comment></comment><comment><USER37> > I think if Apple measured developer satisfaction scores on the App Store, > the results would be jarring.

Why wouldn't the same fear of retaliation prevent developers from being candid in that measurement?

</comment><comment><USER38> We have distributed protocols that make app stores obsolete. We just need to start using those technologies.

</comment><comment><USER39> > This resentment runs deep and is stunningly widespread.

Stunning? :) Right.

Daring Fireball conveniently neglects to mention one crucial bit: _he_ is afraid to speak his mind, because he's made a career out of being 'impartial' when Apple is in the wrong, and the biggest fanboy when they get anything right. ()

> Without touching upon the question of who's right and who's wrong

Wrong according to Daring Fireball is anything that exposes Gruber as an Apple shill and hurts his ability to continue making a living this way. Right is everything that strengthens Gruber's position of being the #1 Apple shill in the world and his ability to make a living.

It's hard to justify begrudging someone who is amoral and just wants to make a living by doing the least amount of work possible. I am just so filled with contempt - a personal failure on my behalf to feel this way.

\---

Somewhat related, to help people understand the 'stunning' resentment towards Apple, the aura of aimlessness and cynicism in America and Western culture:

We live in a corporatocracy [0] (a word that doesn't exist according to dictionary.com and Google's spell check). Almost all of us are wage slaves [1] and those who have a chance at freedom, enjoy their private dinner parties too much to ever speak up for the wage slaves. Why ruffle the feathers of your fellow Aristocrat friends when you're hoping to join or have already joined them?

Don't you know the many perks of being a wage slave master, even if you remain a wage slave yourself?

Oh and those who have become Aristocrat rich? Never have to worry about money rich? Your kids are now part of the Aristocrat family - they'll go to private school, live in gated communities and attend 'elite' universities. You don't need to worry about them wage slaves anymore, they're not as good as you, you were brave and talented in pursuing greed at all costs, you're one of us now, you're not one of them.

Resentment towards the ruling class is centuries old. For a thorough treatment on this topic, there's a masterpiece that spelled this out in a powerful way almost 150 years ago - On the Genealogy of Morality by Nietzsche [2]

[0] [https://en.wikipedia.org/wiki/Corporatocracy](https://en.wikipedia.org/wiki/Corporatocracy)

[1] [https://en.wikipedia.org/wiki/Wage_slavery](https://en.wikipedia.org/wiki/Wage_slavery)

[2] [https://en.wikipedia.org/wiki/On_the_Genealogy_of_Morality](https://en.wikipedia.org/wiki/On_the_Genealogy_of_Morality)

<comment><USER40> I've been reading Daring Fireball for more than 15 years now precisely because I trust John Gruber to call out Apple when they need to be called out.

I'm always surprised to see people who think he's a biased shill - see you reading the same site that I am?

</comment></comment><comment><USER41> > To say that "many developers do not want to speak out for fear of falling > afoul of Apple" is an understatement. Almost none do. And one thing I've > learned this week — mostly via private communication, because, again, they > fear speaking out publicly — is that there are a lot of them.

Seems to me the US has a lot of deep things they can't pronounce lest there's retaliation.

Reminds me of communist Romania honestly.

Of course, we've all read [http://www.paulgraham.com/say.html](http://www.paulgraham.com/say.html)

<comment><USER42> The US has been moving towards more authoritarianism, just like communist Romania did when the system started failing at the seams in the 70's.

Of course, when living inside the bubble, it's not that obvious to people, hence your downvotes.

</comment></comment><comment><USER43> You can't march into a private company and say the rules don't apply to me.

</comment><comment><USER44> "This resentment runs deep and is stunningly widespread"

I am going to offer an alternative here.

The reason why the resentment runs deep and is widespread is that we are beyond "peak App Store". While Apple's revenue on services and the App Store is probably still growing it is because there are still more and more developers piling on.

For the average developer, the golden days of the App Store are long gone. The revenue has been declining for a long time and competition is still getting stiffer. That creates resentment.

Being able to receive a micro-payment of just one dollar and being listing in a potentially powerful marketing channel - the App Store - is a huge bon and something the web cannot offer. Paying 30% for that is reasonable, even cheap.

Should Apple offer discounts for big businesses such as Facebook, Google, Basecamp? Let them have a fee of less than 30%? Maybe. But that will not make Apple more popular amongst average developers.

Mr. dhh is a smart guy and a master nerd manipulator. He knows that the app offering of his new product is not that important and things are ripe for a smackdown of Apple. Also a little conflict helps getting attention on his new product. So he brings this up now even though Basecamp has had stuff in the App Store for years.</comment>


800xchange founder killed by cofounder - <AUTHOR> http://www.latimes.com/news/local/la-me-0901-africa-emails-20110901,0,5139385,full.story

<comment><USER2> This may come off as insensitive, but this story really reads like an episode of CSI.

<comment><USER3> Lax police boarded the plane just before it took off."

I agree. It is quite sad but the cover up was clever.

<comment><USER4> Not clever enough, though...</comment></comment></comment>


3factor apps: a pattern for fast iteration, resilience and high scalability - <AUTHOR> https://3factor.app/ <comment><USER2> So this pattern forces specific technology choices on you (GraphQL), and encourages vendor lock-in by going all-in on "Serverless" cloud functions. No thanks.

<comment><USER3> We do our "serverless" using the self-hosted version of Azure Functions - Azure Webjobs. For most of the events we can scale out to 32 beefy machines. We also don't use graph SQL, preferring simple rest endpoints made in Web Api 2, and some reporting functions. If we need to do more than that...well, we'll have to rethink some things.

It will be a good problem to have.

<comment><USER4> While I agree Azure web jobs are awesome, I'm not sure I would call them serverless. They require you to provision an app service and would only scale within whatever tier you have and ultimately share resources with any sites you have on the same sever.

Microsoft actually has an on-prem or self-hosted version of Azure functions that uses docker, though it's still only in preview.

</comment></comment></comment><comment><USER5> Scaleability means more than just being able to accept infinite requests without buckling. It also means writing predictable code that your teammates (or you 6 months later) can parse and understand whats going to get touched. I would argue thats more important for 98% of the stuff we build. You can iterate faster when you can understand what your changes touch and see the whole picture. Talking to what is essentially a bunch of stored procs on AWS or similar and/or letting your front end team write the database queries to fetch data seems like a massive footgun. Am I missing something here?

<comment><USER6> Hm...not sure why you think this goes against what you're saying. The idea is just to make things more asynchronous and give the front end team the ability to consume async information. Also, giving the frontend team the power to query what they want is not a bad thing. You should have a process to whitelist queries before they go into prod anyway.

Incidentally serverless can also mean microservices. The idea is just to deliberately remove state from inside the code and put it into state or events. And then running that on something that scales 0-n. Why Is that against your principle of scaling the codebase for the team? It's just a dev principle to make ops easy.

<comment><USER5> Let me start this by saying I am a frontend developer. Lest you think I am some curmudgeon coming at you with exclamations of the "good ol' days" of PHP/jQuery...

I'll give you this: you can build something suuuuuper fast with this architecture. I imagine it would be thrilling for the first, say, 6 months or so. Hell maybe even a year if your business rules don't change too radically. In SV that might well be enough. As long as you are building and not maintaining/updating I doubt you'll get bit too bad. Depends on the size of your team. In this case smaller would be better.

Its just that I've yet to see a compelling case for this type of thing for non FAANG companies. They have very very different problems than the rest of us and every one of them started out as a monolith (shoot Google STILL rocks one). To me it makes way more sense to start out as one, maybe two, code bases and then scale off things that need these performance boosts to serverless processes etc as they are needed. The reason being that to be effective in a given system, one needs to be able to understand the ramifications of changes as they are made. Its much easier to do that when you can grok the whole system vs talking to an isolated process.

Let me step through your comments/questions:

> Serverless can also mean micro services

Oh I am aware. Dear god I am I aware... I manage many of these in a given day. These are even worse honestly because they have their own dependency trees and keeping those up to date/compatible is a friggin' nightmare. Then of course there is configuration management. Then there is the case of having to maintain multiple release versions of an app and needing to apply patches to those micro services. Oh and what if you have a multi tenant environment and those are running different versions? Its just a mess. Thar be dragons dude.

> giving the frontend team the power to query what they want is not a bad > thing

On this we disagree. There should be a discussion about this. A pattern to follow and a data contract. The UI should be as dumb as possible and only know about that contract. If that contract is not met, things should go red. I'd be willing to concede that something like a reporting interface or a complex filtering scenario would make sense. I just don't think it makes much sense to let anyone pull down anything they want wherever.

> You should have a process to whitelist queries before they go into prod > anyway.

We agree on this. However, at the risk of sounding snarky, thats what an API contract is.

> And then running that on something that scales 0-n

Again, this is not a problem you need to solve right away. If/when it does arise, there are a lot of steps you can take that are simpler and easier to manage than a bazillion isolated processes that don't know about each other.

Am I saying this is a uniformly bad approach? No of course not. It might make perfect sense for your org. I am just saying that for most of the type of work I've done, the real scaling issues that I've encountered come from premature optimization and unnecessary obscurity.

<comment><USER6> Thanks. This is helpful!

One question on the API contract, giving frontend teams power thing: what are your thoughts on things like firebase on the one hand and graphql on the other?

</comment></comment></comment></comment><comment><USER7> Looks like a multitier architecture plan to me. I see an app tier, a logic tier implemented in GraphQL, a state tier, and a functional services tier.

[https://en.wikipedia.org/wiki/Multitier_architecture](https://en.wikipedia.org/wiki/Multitier_architecture)

Also see the 12 factor app guide, which aims to improve adaptability and resilience.

[https://12factor.net/](https://12factor.net/)

</comment><comment><USER8> I think this really boils down to:

      1) Have an api gateway (for them, graphql).
      2) Store state in a (most likely distributed) store.
      3) Have services interact with state via an event system.

All this really says is make your applications stateless. This is a trend that has been going on for a while.

I don't think GraphQL nor serverless is required and are just specific to their implementation.

Unless I totally missed what they were going for.

</comment><comment><USER9> So basically you've renamed your API layer, graphQL

one note, using serverless doesn't allow you to scale to infinity. You are still dependent on your database/state management.

<comment><USER10> I don't have any experience, but isn't it generally encouraged to use DynamoDB or spanner for faas on aws or gcp because of that?

<comment><USER9> Its possible, but that that scale how your model your data, and what and where you want your data to be become very important.

If you need global state, then dynamo _might_ help, but that's still limited to a region. Yes there are mechanism for syncing regions, but you need to decide what's more important, consistence, or speed.

</comment></comment></comment><comment><USER6> Hi HN!

Wrote this up based on our experiences working with early adopters of GraphQL and serverless. There have been lots of teething pains with serverless architectures and we've seen this as being a useful way of pushing business logic to being "serverless" which is run asynchronously and the results are captured asynchronously too. That way you don't have to worry about cold- starts and a lot of error handling and resiliency concerns go into the generic event system.

GraphQL subscriptions also fit in really well because they allow clients to consume asynchronous results.

Feedback, ideas, experiences very welcome!

<comment><USER11> The issue I have with your website compared to the 12factor one is how hard it is to grasp/implement your advices.

> 12Factor Nbr 3 : Store config in ENV variables.

Yep I can do that. In 2 hours I can convert most of my conf in env var. And my next project will go with ENV var from the start.

> 12Factor Nbr 11 : "each running process writes its log, unbuffered, to > stdout"

Yep, give me 5 minutes to do that.

When I read 12 factor, and decided to give it a shot, by the end of the week, my app (2 devs full time for 2 years) got nearly everything nailed down and I was able to benefit from it. The last remaining points were harder to implement but I undestood what I needed to do and why.

Most of the advices of the 12factor manifesto can be applied to any programming language/framework/architecture/buisiness and make the deployment/management of the app at least easier.

When I read your manifest, I did not understand most of it. Even your examples do not "talk" to me :

> In your food ordering workflow, instead of writing a payment processing > microservice that captures different failure modes, write a payment > processing function that processes a payment or fails. The event system > should capture the retry or failure event which is processed thereafter. > This ensures your business logic is simple and easy to scale.

What event system ? how does it capture the failure mode ? I have an app that is now 4 years old, on which 6 devs are working full time, what can I do today to make it better in a month or two ?

Why are your trying to force me to use GraphQL and make a tech choice for me ? At no point 12factor says use "HTTP REST JSON API" even is a lot of user will go that road, it's their choice and not forced by the maifesto itself.

<comment><AUTHOR> > What event system ? how does it capture the failure mode ? I have an app > that is now 4 years old, on which 6 devs are working full time, what can I > do today to make it better in a month or two ?

Good question. Definitely the wording can be improved. Let me try to explain though.

Suppose you write a simple function which processes payment. It fails. Now you can insert a state saying failed with error code 1001. Now this insert creates an event which invokes a serverless function specifically aimed at resolving this error.

This way you have smaller cohesive functions which do "atomic" work as much as possible.

PS: Co-author here.

<comment><USER12> What is a "serverless function"?

<comment><USER13> I'm guessing they mean something like AWS Lambda.

</comment></comment></comment></comment></comment><comment><USER14> tl;dr:

>[An] architecture is analogous to the redux dataflow model on a react app, but applied to the fullstack.

The page has no concrete recommendations as for what tools could work to implement this pattern except GraphQL. Without a pretty strong knowledge of the tools out there, you won't know how to implement this architecture pattern well.

There's a lot of hand-waving past non-trivial problems and there's not much help on what tools/patterns/best practices will help that. For example, the architecture requires a fully async backend, yet that all state changes be atomic.

Similarly, the architecture requires `Your event system should deliver the events reliably to other microservices.`. Not a trivial thing to achieve.

Also, this architecture promises to `Scale your backend infinitely` because of using serverless services, but because everything is being funneled through a centralized state, That server/database has the potential to be a bottleneck that keeps you from scaling, and the architecture has no advice as to how to build your state to be scalable.

</comment><comment><USER15> So let's say an event is emitted, does this happen?

* "payment processing" handles it -> changes state -> another event emitted -> "restaurant approval" processes it -> changes state -> another event emitted -> "delivery assignment" processes it

Or does this happen?

* event emitted -> "payment processing" and "restaurant approval" handles event asynchronously, -> state changes -> event emitted -> "delivery assignment" handles event.

<comment><USER16> So instead of clear code to handle the error you have a dozen logic components watching for some events and modyfing state again triggering events and modifying state. Yeah, i absolutely can see how this approach will NOT increase maintainability because now you have 84 logic functions watching for some graphql events, and they may never be down for a microsecond because they would miss a (critical) state change: graphql subscriptions are not like persistent queues

<comment><AUTHOR> That is why events must be persisted and reliably delivered. And in the frontend, you must subscribe to the state of the world and not necessarily each state change. This way if frontend goes down and comes back up you can show the new state instantly.

<comment><USER3> Exactly. We created our own even store on top of a SQL database. It's quite simple to do, and it is blazing fast because it is custom built for our use case. It's an append log of every event, their time, their type, and some other info about them (account, user, etc.). The event itself is stored as json, and we can just use Json functions of SQL Server to query those for diagnosis if need be. We've also got failure reporting built in, and strict referential integrity for various other tables to link into the main event storage table.

It was actually a pretty fun weekend project.

<comment><USER15> Right. But, what if the client (eg browser) would ask the system if the message has been fully processed? Then the client can re-send the message if the Server lost the original message? For example:

      client: "Hey, buddy! Did you process that message I sent you? Here is the ID."
      Server: "No. Send it again."
      client: "Ok. Here is the message again."
      [Server processes it, completes processing it, sends back response.]

If done this way, wouldn't you be able to reduce the need for persistence of the original message and events from the client? (Not that persistence of the original event on the Server would be a bad thing.)

<comment><USER3> We can do this via the store's aforementioned failure reporting. I guess it could be better? I prefer to have a log of all messages since forever, as in Event Sourcing.

Seems like that is more trouble than it's worth to try to make everything happen purely on a message bus, though the mechanism for letting the system know a new event arrived is a message bus, it just includes the message id, for us.

</comment></comment></comment></comment></comment></comment><comment><USER17> I'm waiting for 1factor apps.

<comment><USER3> "Just write teh coad"

</comment></comment><comment><USER18> I've never used GraphQL, would using it mean I do not have to define DTOs or other API objects, I would just create models from whats been passed into GraphQL?

Talking in a Java context here.

</comment><comment> ah- What would you use nowadays to actually implement the real time GraphQL subscriptions and event system in practice?

<comment><USER6> We built [https://github.com/hasura/graphql- engine](https://github.com/hasura/graphql-engine) , [https://hasura.io](https://hasura.io) that sets up the plumbing for this architecture with state being Postgres.

There's a lot of other tooling emerging in this direction too. For example, set up a GraphQL server and subscriptions with Postgres and listen/notify and use SQS with lambda. Or dbezium + Kafka + custom service for event delivery.

</comment></comment><comment><USER19> "3factor" strikes me as a bad name. In IT, 2-factor universally refers to login security/multi-factor login. "3factor" sounds like you're adding another security method to the login screen.

<comment><USER20> It's a play on "The Twelve-Factor App" [https://12factor.net](https://12factor.net).

[https://3factor.app/#comparison- to-12factornet](https://3factor.app/#comparison-to-12factornet)

<comment><USER21> This may be silly, but I think copying the format and spelling out the number might make this look less like "2-factor":

> The Three-Factor App</comment></comment></comment>


Writer's Block and Introspection - <AUTHOR> http://softwarecraftsmanship.oreilly.com/news/2008/7/8/writer-s-block-and-introspection

<comment><USER2> _I'm old, Gandalf. I know I don't look it, but I'm beginning to feel it in my heart. I feel... thin. Sort of stretched, like... butter scraped over too much bread. I need a holiday. A very long holiday._</comment>


System.IO.Pipelines – High Performance IO in .NET - <AUTHOR> https://blogs.msdn.microsoft.com/dotnet/2018/07/09/system-io-pipelines-high-performance-io-in-net/my <comment><USER2> You have a typo in the URL, a "my" on the end.</comment>


Google introduces Loopt competitor - <AUTHOR> http://www.google.com/latitude/intro.html

<comment><USER2> That's was the reason why google shutdown Dodgeball!

There were lot of other start ups with similar services that are going to struggle due to this service. .

</comment><comment><USER3> I tried it out on my Blackberry curve. Works well. The bubble that pops up with a friend's picture and status is neat. Unfortunately only 2 friends have it installed. I had to zoom out to see both California and Colorado before I saw more than myself on the screen.

Reminds me of the time when I had to wear one of those bracelets as part of my parole.

(kidding)

</comment><comment><USER4> Hmm, I can't imagine this working very well for the iPhone with no background application support, unless it makes it into the real Maps application and they provide an option to broadcast while it's not running.

</comment><comment><USER5> No popped collars. Less SMS spam than Loopt. Lame.

</comment><comment><USER6> Not available for the iPod Touch. Just like Loopt.

Yeah, yeah, I know Latitude says "soon".

</comment><comment><USER7> How many times does this need to get reposted?

<http://news.ycombinator.com/item?id=465474> <http://news.ycombinator.com/item?id=465458>

<comment><USER8> This submission is from an official source (Google itself) and the headline mentions Loopt (a Y Combinator project), so I appreciate this addition to the discussion of this hot story.

</comment></comment><comment><USER9> First screen shot shows Montreal!

<comment><USER10> I think it detects where you're located and put some relevant map because I see the SF Bay Area personally.

<comment><USER11> IT does, I see Copenhagen.

Very clever little detail.

<comment><USER12> I saw one of "my friends" up on the mountain summits around Innsbruck.

</comment></comment></comment></comment><comment><USER13> broke my BlackBerry 8800</comment>