imperialWicket

This is a great callout.

I think for a newcomer this is where loading an existing game (like Celeste...) and just changing sprites or updating logic gets you some of the non-built in features for free - but at that point you're more modding someone else's game more than creating your own. I can see how that path could be a non-starter for some folks (no matter their age).

It falls short on your 3d request, but for someone new to things I'd go down the pico-8 rabbit hole.

There are some really spectacular (given the limitations) 3d games, but they're the exception. However, the IDE is built-in, it's basically lua, and you can load/view/edit the source code for all the published games.

https://www.lexaloffle.com/pico-8.php

Some newcomer-friendly tutorials: https://nerdyteachers.com/PICO-8/Bitesize_Games/

Pairing A Patriot's History and A People's History makes for some interesting perspective. They don't really offer explicit points/counterpoints, but they certainly frame things differently over similar time periods (which cover America's coming of age to a powerful world presence).

https://www.amazon.com/Patriots-History%C2%AE-United-States-...

https://www.amazon.com/Peoples-History-United-States/dp/0062...

- childsplay https://childsplay.en.uptodown.com/ubuntu (mentioned elsewhere)

- doudou linux http://www.doudoulinux.org/web/english/index.html (an entire linux distro that wraps gcompris and includes other child-specific apps/features)

DevOps is a moving target right now, and a lot of great fundamentals are linked here already. I'd also recommend subscribing to, and reading old issues of:

https://sreweekly.com/ http://www.devopsweekly.com/ https://lastweekinaws.com/ https://weekly.monitoring.love/

The last two are fairly young, but have good content so far. I wouldn't call it a well-curated list, but there are tons and tons of great posts are linked (in loosely chronological order, as weekly mail blasts tend to be).

I've got a 5 year old Leopard and a 1.5 year old Wild Dog that are perfectly satisfactory. I have a month old Oryx, and my sentiment follows the general comments - I'd probably spend just a little more to go Dell/Lenovo for the next laptop. The rebranded Clevo machines just aren't the same build quality and on a laptop (for many users) that's a meaningful issue.

If you did have an iTunes account, you were prime for an iPhone purchase. That demographic had a clean experience of buying a mobile device that was super-capable (someone could pretty much out-of-the-box sell you things, without having ask for information - like a cc #). None of the existing devices had this, and it would be a long time until anyone was even close. I don't think this is a point of disconnect, I was highlighting one of the sometimes overlooked (imo) aspects of Apple's longer-term execution that I think made an impact.

Fair point on the competitors. It's hard to ignore Android as a competitor, and I might disagree with saying that Android wasn't an "original" competitor. But if you mean original as "existing at launch time", I'll happily agree (But by that definition, iPhone isn't a [original] competitor to Nokia/Blackberry/Windows, it just happened to destroy them - EDIT - it's a fair distinction).

Monetizing was Apple's success, but in the early iPhones, I'd argue it was a lot of carry over from iTunes. Apple forced you to have an Apple ID, and associated with the Apple ID meant they could seamlessly sell you things and charge you for it. At the time, no one else had this position and it made a huge impact for the iPhone as a successful device in a rapidly changing landscape (phone as phone -> phone as device to buy from carrier/provider -> phone as device to buy from marketplace).

Also: "none of the original competitors even survived"? Are you talking about tech like Sidekick here? Samsung/LG were big players in early Android, and they're obviously still around. There's a huge amount of discussion around BlackBerry, Nokia (Symbian), and Windows - but to say that none of the original competitors even survived feels hyperbolic.

Not strictly related, but on your second point - http://www.libertypuzzles.com/ makes some really great puzzles that have very unique ("whimsy", iirc) pieces. I've gotten a few for my children and found that I enjoy putting together the easier puzzles as a speed challenge. The unique pieces make "timed-runs" quite interesting.

Kiwi Crates (and Koala - haven't tired the older age targeting boxes) are excellent, our 4 and 5 year olds love them. The results don't have a lot of longevity, at least for the Kiwi crates, but they consume an afternoon+ and involve a lot of productive-feeling efforts.

I have been thinking about genius box, the young scientist club, explorabox, and agent ribbit, too. There is so much overlap in a lot of these that it's difficult to commit to multiple without just ending up with duplicates. That probably wouldn't be entirely bad, but it's mildly annoying. Also, not all of these get down to the 3-4 yr range, but maybe something to think about in the context of the impending TinkerCrate subscription.

http://www.geniusbox.me/

http://theyoungscientistsclub.com/

http://www.explorabox.org/

http://agentribbit.com/

I use a git hook that builds locally on commits to master (with some cleaning just in case I was testing weird things from non-master). I host on s3, but I don't think the s3 transfer vs github push is of great consequence here.

This is great supplemental data, much appreciated!

Lots of people are already using it, so it has familiarity (I was thinking more than pgbouncer, pure conjecture though).

I think if you wanted to have the simplest possible solution, pgbouncer and postgresql-specific replication mechanism would be perfect. This is along the same lines as my question - I don't really see how these alternate solutions could be construed as lacking...

This seems robust, but feels like more moving parts than are necessary.

I feel like HAProxy with PostgreSQL + Bucardo (multi-master + at least one slave) would achieve this, and net you fewer moving parts. Under what circumstances does this fail where the etcd-dependent solution succeeds?

Packer is great for generating AMIs, particularly if you're already using some form of config mgmt. It will let you tie in your existing puppet/chef/salt/ansible/shell/etc. and output amis based on your config.

This got me; often you want clock_timestamp() or timeofday().

I wrote about it, too - http://imperialwicket.com/postgresql-getting-now-in-function...

ELK and others have been mentioned and are great tools, but if you want a more simple solution within the Sql realm postgresql with table partitions works well for that particular problem.

I agree with many comments that this isn't ideal, but setting up weekly/monthly partitions might buy you plenty of time to think through and implement an alternative solution.

Per-second metrics and a (claimed by netflix) pluggable system for custom metrics that's likely easier than pushing custom cloudmetrics data.

Some data from Netflix employees here: https://news.ycombinator.com/item?id=9339698

Since logstash was already mentioned, it's worth putting https://github.com/elasticsearch/logstash-forwarder here, as the logstash team built it as a solution for logstash-type needs on systems that may not be able to support logstash itself.

I made a data star supporting weather/water sensor data in postgresql that heavily relied on table partitions for handling performance [1]. We had it on pretty weak machines, replicated with bucardo, and never had any issues. It worked well to several million records/month (not sure where it is now).

[1] https://github.com/imperialwicket/postgresql-time-series-tab...

That's a meaningful data point, and impressive! Nonetheless, I think Opera is exceptional for a few reasons and for a smaller dev, there's little practicality to J2ME. It's much more difficult to charge for or in your apps, and without a known brand, having your own wap or download site isn't productive because you still won't get much traffic.

I'm really just highlighting that while some of the aspects have allure, many of the challenges that are present in the current 'mobile' (android|iOS) landscape are simply heightened in the j2me world.

Another huge challenge with J2ME application development is the marketplace options. Most of these are carrier controlled, and you must pass certification tests per carrier, per device in order to make your application available. While some devices/carriers will allow easy J2ME 'side-loading' (never called that in the J2ME world), almost no one does it.

Additionally, most developers are aware that mobile app purchases most often happen immediately after the purchase of a device, and lots of users never buy another app again. This is even more stark a scenario in the J2ME world (particularly in the US - though we make up a small amount of the J2ME devices in use).

This isn't helpful. It's a perfectly valid question that even provides insight into some possible candidates. The candidates might not be the best options, but they commonly serve this purpose.

What is it about RabbitMQ or Redis durability that you find lacking? What alternative do you recommend?

It does come apart (you can buy keys with key tools in accessories). Or you could get the ultimate with blank keys.

I was thinking the same thing... But Newton and Lobachevsky make for a much more challenging 3rd and 4th edition.

This is great, particularly based on some of the feedback in the comments. The diagrams seem differ from the recipes in a few places, I assume these are hardcoded at this stage?

Once you get things in order for batch size conversions and clean up consistency, it would be neat to support efforts within the resulting community. I'm sure these are on your radar, but things like batch challenges (where others try their hands at brewing your recipe and blind taste test) and community provided/selected batch modifications for limited runs could be a lot of fun.

I'm looking forward to more posts as you move forward.

This is a pretty old article, and not much seems to have happened in LoggerFS development. Maybe log shippers aren't so bad after all?