adamesque

the parent literally typed that they used to do just this, didn't have to anymore thanks to Simple, and didn't want to go back.

I'm also a bummed Simple customer and they made it so easy to set up buckets for literally anything with zero overhead, which encouraged a ton of saving from me.

Same as a regular fission plant if I'm not mistaken!

It’s also easy to overlook, but at the time PUBG was nearing peak impact, the only console version was a buggy Xbox port. I remember being completely taken in with PUBG streams but with only a PS4 had no way to play.

I downloaded Fortnite certain it was a hack and a ripoff but it was literally the only Battle Royale-style game available to me at the time. Being free and on all platforms out of the gate was crucial.

Reminds me a lot of Bandcamp, which serves a similar market and has a similar and very refreshing ethos: in it for the long haul, dedicated to serve their audience because (likely) nobody else will, because there's not and never will be VC-sized 100x upside.

It has a ton of rough edges (for instance, doesn't use the same media playback APIs as the rest of the system so playback dies if you turn off the screen) (also for instance, it routinely gets "stuck" looping through a tiny tiny maybe 100ms section of a song) but despite those it's become my go-to catalog for recording song sketches. Oh — I also use and rely on the rating and tagging features.

I used to use the Soundcloud app for this very early demo songwriting phase but that's not really what Soundcloud is about anymore.

I am on Safari, so yeah, maybe that's it.

Thanks for the responses!

I'm also thrilled to see more songwriting tools on the web! As an active songwriter, the area I need the most assistance with is lyrics. To that point:

- It'd be great if the rhymes panel was larger (or resizable). I use RhymersBlock on iOS which has a kinda neat way of color-coding rhymes within your lyric.

- Something I desperately need that no app has implemented is a way to build lyric "alternatives" on a phrase by phrase or line by line basis so that I can swap in an alternate lyrical treatment and see it in context. (Revision history would be a related and also probably very cool feature)

- I personally don't think I'd have much use for chord progression suggestions, but that's just me.

- I can't currently move a chord annotation while that annotation is selected. Have to click off of it to deselect before dragging works again.

- For chord annotations, it's often useful to be able to "split" the chord into the chord + bass (or root?) note especially for passing changes. You see this all the time in Beach Boys songs.

- Apple's Music Memos app has a bunch of audio analysis capabilities that I realize I use a bunch. They extract chords (which I don't use very often) but more importantly, they auto-detect a BPM from a recording which I use as the starting point when I'm ready to move from demo -> production.

I'm really excited about this app. Here's hoping it turns into the "Songwriter's notepad" I've always dreamed of!

An individual contributor is just someone who doesn't directly manage other people.

I think you're supposed to use it to refer to people who are evaluated by their own work output as opposed to measuring the output of a team (even though I think for senior engineers it's totally valid to evaluate whether they're boosting the team and nudging them towards better solutions).

Well, the iPod came out in 2001, and was already a huge phenomenon when the iTunes Music Store launched in (I believe) 2005.

So you can't give all the credit for why the iPod succeeded to something that didn't exist for those crucial first 4 years.

It sounds like the core team is contemplating doing LTS releases, which should ease the fears of anyone who worries they'll be left behind if they can't keep up.

source: https://github.com/emberjs/rfcs/pull/84#issuecomment-1304511...

Not really — if you were paying $35/month JUST to have always-on dynos, you should be able to downgrade to the $7/month hobby tier.

If you really needed that 2nd dyno for performance reasons, then yeah, it's a price hike.

Reaction, Inc - http://www.reactionhousing.com - Austin, TX - Sr Software Engineer (Ruby/Backend)

Reaction needs a senior software engineer to help house people displaced by disaster

At Reaction, we're building a smarter, lighter, more humane shelter for people displaced by disaster: the Exo. It's stackable, modular, and light enough for a small group to carry and requires no tools to assemble — perfect for the immediate aftermath of a disaster, when a secure place to sleep can mean the difference between hope and despair.

The Exo is also stunningly designed and truly smart, with built-in brains and cutting-edge mesh networking hardware and sensors.

Alongside the Exo, we're building a software platform to help organizations manage and monitor Exo villages, and that's where you come in.

We're an informal, friendly, and close-knit team deeply driven by our mission to help people using equal parts design and technology.

-- About the Job --

We're looking for a seasoned engineer who can help us build our backend software platform. You'll work on the Rails API that powers our web & mobile client apps, the databases that power the API, and the mesh networking services that allow our platform to talk to our shelters.

We're committed to continuous deployment and a test-driven development style.

Down the road, you'll help us ensure our mission-critical systems' uptimes have enough 9s, build complex mapping applications using geo data, or find a way to make our platform work even for Exo villages with spotty internet connections. We'll quickly ramp into some interesting and difficult technical problems.

-- About You --

Like us, you love Ruby. You have a solid grasp of the entire web stack: HTTP, RESTful API design, storage systems both relational (Postgres) and not (Redis/Cassandra/etc). Experience with queues and distributed systems a plus.

Although you may spend most of your time on the command-line, you prize thoughtful user experiences and design, and would be excited to work in a design-led organization.

You love asking and answering questions, and go out of your way to explain technical matters so that anyone can understand (and feel empowered for asking).

Most importantly: you're a friendly, effective person who feels deeply drawn to Reaction's core mission of helping people all over the world.

We're actually pursuing a similar model at Reaction (http://www.reactionhousing.com), convincing commercial customers who buy units to also buy units to donate.

We'll see how it works in the long run, but initial results have been encouraging.

Yep, we've built a number of pre-production units. Hoping to go into production later this year.

There are a few non-rendered photos on our media page: http://www.reactionhousing.com/media/

And another few in an article about us in Popular Mechanics: http://www.popularmechanics.com/technology/a14357/exo-shelte...

please do!

Heh, it was actually designed by our CEO, a designer from Mississippi — he's been working on the concept since Katrina, finally got it funded a year ago.

There's a startup in Austin, TX aiming to compete in a similar space: http://www.reactionhousing.com

Full disclosure: I work there. ;) And if you find this sort of mission compelling: we're hiring software engineers! (firmware, backend) http://www.reactionhousing.com/careers/#embedded-firmware-en... http://www.reactionhousing.com/careers/#software-engineer

Our design is quite different (and geared towards a shorter length of stay) but all the same, I'm excited to see these go into production.

Whoa! Love the idea of a hybrid lua/markdown file; I didn't realize that the readme for the Github project WAS the source code till I noticed it was just a symlink to the .lua file.

Very cool.

Wow, the colors are just gutted in the mp4 version.

I'm not sure I've ever met an opinion on a logo, name, or anything creative less than a month old that was worth a damn.

When faced with something new, the tendency is to focus on the superficial, the easy joke, and it's too easy to let other opinions steer your own; they're momentarily on equal footing, you see. But the work will last longer than this moment. Your own opinion will evolve. The crowd will move on to the next easy joke and hip-shot reaction.

That's why I like to avoid making more than cautious, small statements until I've had a while to reflect. This work looks nice to me. There's potential for great marketing in an individually customizable — but still distinctive (or distinguishable) — logomark.

Most of this commentary feels like the person in the code review who hasn't taken the time to digest the intent of the code, so they comment on formatting. Whitespace. Trees. Not the forest.

I spent my first few undergrad years as a CS major at UT before this change happened, and had no prior experience with programming (I started in '97).

The INTRO-intro CS class at the time actually used Pascal, and was endlessly confusing to me as a cold beginner.

My next course, however, was taught in Scheme, and immediately I felt more at home. And for the first time, I felt like I might have some actual aptitude for programming.

Without that peek into the elegant heart of computer science, I doubt I'd have stuck with it as long as I did.

We did one demo that was more or less floating above static terrain, and another with Half-Life 2.

My own nausea didn't actually start up until HL2. We were playing on a laptop (probably not enough horsepower), using slightly unfamiliar keyboard & mouse controls. So some movements were very fluid & second-nature to me, while others were jerky and off because of the slightly-off control scheme.

It's possible the most nauseating moment was taking the headset off, actually. Up to that point, my mouse hand had been a pretty accurate proxy for my in-game hand and arm, but taking my hand off the mouse and then ripping the "world" away with that same (now "phantom") hand was deeply disconcerting.

But it's also possible the nausea built up slowly over the course of playing. I'd love to spend more time with it to see if it's something you really can adjust to.

I got a chance to play with an Oculus dev kit for 15-20 minutes over the holidays, and almost everyone who tried it walked away with some pretty gnarly nausea (experienced gamers and newcomers alike). I'm excited to see so many of the updates in the new prototype focused around alleviating this discomfort.

It's probably telling that they're couching the updates in language that addresses this, rather than just touting the technical accomplishments.

Suppose a "hidden truth" turned out not to have been intended by the author — would that make it less true?

One of the beautiful things about art (and life) is that it literally is what we make of it (or what we can make from it using the evidence at hand).

Authorial intent is super interesting, of course, and can enrich your understanding, but it's also pretty rare information. Often the work itself is all that remains after the author's gone.

At that point, it doesn't matter what the author "meant". You read what they left you to read and get whatever value from that you can.

Completely respect where you're coming from, but totally disagree. I made a few abortive switches to Vim that didn't last a week because my productivity was too hampered and the environment too extreme & foreign.

To a newcomer like me, Vim's built-in help was less than worthless, since you pretty much need to know the Vim term for what you're looking up to find it. Googling around wasn't much more effective (there's a lot of garbage in the Wikia for Vim that comes up at the top of many searches).

In the end, I needed to read these two "gentle" introductions to Vim to even understand what it was all about:

http://stevelosh.com/blog/2010/09/coming-home-to-vim/

http://yehudakatz.com/2010/07/29/everyone-who-tried-to-convi...

…and then I needed a mostly-well-documented distro like Janus (https://github.com/carlhuda/janus) to ensure that my productivity wouldn't take a huge hit those first few weeks.

Some folks can probably go all-in cold turkey, but I needed the training wheels.

I commented on this elsewhere, but this didn't break my zoom at all — although I did have to bump it up to around 200% to start seeing increases. You could argue this is inconvenient, but not quite broken.

I had to bump the demo site up to about 200% to start to see increases, but was definitely able to increase the text size.

The most interesting part of the article (which is well-written and thought-provoking) isn't the mildly alarmist "regressive web" assertion, but the insight that Reader may have been killed because it was strategically opposed to Google's mission as it enters the mass-market phase of its growth.

Which mirrors the developmentally mass-market phase of the growth of the internet itself.

That doesn't necessarily mean that niche tools won't continue to be available to interested specialists. Ham radio kits are still around, right?

I'm not sure that the macro view of the web is as bleak as it seems. We're seeing mass-market effects take hold in our playground, which is a bummer, but we're also seeing mass-market adoption of tools which help keep information democratized and flowing freely in multiple directions, which is an improvement on the past 2000 years.

If I've understood correctly, the most compelling argument (or at least the most seemingly objective one) is that CoffeeScript conflicts with planned features of ES6+, meaning that there is a risk that large CoffeeScript projects will be locked into the ES5 feature set.

Since Discourse is planning on being around long after ES6 becomes widely available, it was a winning argument.

http://meta.discourse.org/t/is-it-better-for-discourse-to-us...

Also, one of the big reasons the Discourse devs liked CoffeeScript is because it makes it hard to commit common JS errors. Building JSHint into their workflow can help bring this protection back.

It's easy to forget just how developed our pattern-matching abilities are as seasoned programmers. The inability to recognize, find and fix transcription errors is the single biggest challenge I see new folks struggle with. (A close second might be the realization that, yes, every single character matters.)

I can't even remember how long it took me to develop those skills, but it's interesting how far back I slide when working with a new language or toolkit.