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

Aha! (https://www.aha.io) | Rails / React / Devops | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than 700,000 users worldwide. We are looking for:

* Experienced full-stack Rails and security engineers to work on the Aha! product. Our application is built in Ruby on Rails, with React on the frontend for rich client-side experiences.

* Devops engineers with Ruby experience. We focus on the "dev" and all of our operations driven by code.

Aha! is profitable, you can work from anywhere in North or South America, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.


Aha! (https://www.aha.io) | Rails / React | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than a million users worldwide. We are looking for:

* Experienced full-stack Rails and security engineers to work on the Aha! product. Our application is built in Ruby on Rails, with React on the frontend for rich client-side experiences.

Aha! is profitable, you can work from anywhere in North America, South America or New Zealand, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.


Aha! (https://www.aha.io) | Rails / React | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than a million users worldwide. We are looking for:

* Experienced full-stack Rails and security engineers to work on the Aha! product. Our application is built in Ruby on Rails, with React on the frontend for rich client-side experiences.

Aha! is profitable, you can work from anywhere in North America, South America or New Zealand, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.


Hey there. I've applied to your open RoR dev position, like, a bunch of times- and have not once even heard back. No rejection, no update, no nothing. Is this offering real? I'd still like to throw my hat in the mix but am not sure what the next step is when there's no feedback loop?


It is real. I am the CTO and co-founder of Aha!, and also personally interview every engineer we hire.

A human reviews every job application we get, but unfortunately we can't respond to them all - we get thousands - but most of the applications are not related to the position requirements at all. I can tell you that if your resume matches what we are looking for then we typically schedule an interview within a few days. I see that you posted this same comment previously. Commenting was already locked by HN by the time I saw it then.

Why do I keep posting on HN? It works. The profile of engineers we have hired for our team, and the sorts of engineers who read HN has a great overlap. There are other things we look at too. Your Github profile is really important: people who contribute to open source have demonstrated their ability to work on a distributed remote team, but even more importantly it gives you a way to show that you can tackle interesting problems in interesting ways.


Why don't you guys at least send rejection emails instead of ghosting people? Seems like that would be the "lovable" thing to do.


I have seen the variation of this question so many times - I am surprised HN does not auto-delete AHA posts.


No, I don't believe this is a real role. There was a reddit thread about this awhile back.


The seamless integration between one type of object and another is really impressive. The way that the blocks in the roofline perfectly work regardless of the height of the roof is a great example.

How is this possible? Is it some kind of procedural geometry that fills in the available space?


As far as I know they are using a customised variant of the "wave-function collapse" technique, used and popularised by Oskar Stalberg in his games "Bad North" and "Townscaper". The technique boils down to hand-crafting tons of tiles with adjacency rules about which tiles can slot together. When the user adds/removes a tile the algorithm iteratively tries to find fitting tiles and, if needed, changes neighbouring tiles for ones with the best transitions. He gave a talk where he goes into detail about this[1]. You can also find more if you google his name and "wave-function collapse". [1]: https://youtu.be/0bcZb-SsnrA


It is surely procedural, maybe wave function collapse? I’d love to read a writeup from the author, in the same style of Factorio’s


I can't remember where exactly but I think I did read somewhere it was based on wave function collapse.

I think wave function collapse is still super underexplored in game dev. This recent paper is pretty interesting: https://dl.acm.org/doi/10.1145/3582437.3587209


The texture is certainly procedural for brick patterns, etc. but I'll bet smoothing intersecting polys happens at render time.


Just a clever shader


Aha! (https://www.aha.io) | Rails / React | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than a million users worldwide. We are looking for:

* Experienced full-stack Rails and security engineers to work on the Aha! product. Our application is built in Ruby on Rails, with React on the frontend for rich client-side experiences.

Aha! is profitable, you can work from anywhere in North America, South America or New Zealand, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.


It seems that the pilot error here was to fly into severe icing, or to staying in icing conditions beyond what the aircraft was capable of handling.


Or to not recover properly from icing.


I think the original author is drawing the wrong conclusion here. Sully may have had the stick all the way back, but that doesn't mean it was wrong. The lowest energy way to land is to try to prevent the aircraft from landing. So when you are in the flare, the technique is to pull back on the stick to keep the aircraft in the air a few feet above the runway, until you have no more elevator authority, and the aircraft will settle onto the runway with the least amount of energy. Exactly what you want in a off-field landing too.

As my glider instructor put it: those last few seconds before touchdown are the prime rib of flying. Keep pulling back on the stick and make it last.

In fact if you look at the Wikipedia article that the OP linked to it suggests that Sully was unhappy that the aircraft was not responding to his full back stick:

> However, Sullenberger said that these computer-imposed limits also prevented him from achieving the optimal landing flare for the ditching, which would have softened the impact.


My understanding is that transport-class aircraft (i.e. large passenger jets) are typically landed differently than smaller planes like a Cessna Skyhawk or a glider. In my brief flight training experience in a small plane, I was taught to stall the A/C just above the runway as you describe. However, I believe ATPs are taught to land at about 1.3x stall speed, then use the spoilers to dump the lift entirely and get full weight on the wheels in a very controlled way.

I'm of course discussing typical on-field operations, not emergency dead stick ditchings. I don't know how those are supposed to go, but one might imagine that going to full stall just before impact would indeed result in the minimum energy state. The trick is to not accidentally do that too high!


From what I read "the stick all the way back" is correct, because it's telling the computer your intent, "raise the nose of the plane". Airbus aircraft use flight laws to control the actual control surfaces, so there's no reason to make your intent less strong than it actually is.


Airbus airplanes have several different flight law modes (including direct law, which has no protections). So the biggest risk is probably that it switches laws and actually tries to carry out what you're doing.


I know, for all of Boeing's problems not doing that is a big plus. At least on the 777. I hope they haven't changed that since.


Aha! (https://www.aha.io) | Rails / React | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than a million users worldwide. We are looking for:

* Experienced full-stack Rails and security engineers to work on the Aha! product. Our application is built in Ruby on Rails, with React on the frontend for rich client-side experiences.

Aha! is profitable, you can work from anywhere in North America, South America or New Zealand, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.


Aha! (https://www.aha.io) | Rails / React | REMOTE

Aha! is the #1 tool for product managers to plan strategy and roadmaps. We serve more than a million users worldwide. We are looking for:

* Experienced full-stack Rails and security engineers to work on the Aha! product. Our application is built in Ruby on Rails, with React on the frontend for rich client-side experiences.

Aha! is profitable, you can work from anywhere in North America, South America or New Zealand, and we offer excellent benefits. We use our own product to manage our work (which is especially rewarding) and we deploy continuously.

Our entire team has always been 100% remote - in North American timezones so we can collaborate during the work day.


I have seen your security engineer job ad consistently up since I was looking for my last job in 2021. Loking through my linkedin 'top job picks for you' I see this job role first come up June 15th, 2020.

How can you not have found a someone since then, or does everyone quit? I had seen this ad so often I was starting to suspect it was part of a information gathering scheme for information security professionals.


We really are looking for a security engineer with a strong Ruby development background. As our engineering team grows the security team needs to grow in proportion too.

We aren't just harvesting resumes. That idea is a kind of laughable - carefully reviewing resumes is a huge amount of work. I would love to get fewer resumes, but just ones that for candidates with a great match. I can also tell you, without offering any proof, that our hiring is not driven by attrition.


Given the volume of resume spam these days, do you have any tips for getting eyes on my application?


> React was originally designed to be the V in MVC.

So much this. As we built more sophisticated apps using React we were constantly frustrated with how much code was ending up in the views, and how difficult controller frameworks were to work with (looking at you Redux). So we built our own mini-framework that explicitly separates the view from the controller. Seems like a simply change but it is amazing how much more productive it makes developers, especially with large complex applications that need refactoring as they evolve.

Unfortunately our skills are in writing code, not marketing, so we don't have a fancy website like most frameworks. But the details are here: https://github.com/aha-app/mvc


You missed the point. React is not MVC, and that's by design.

Certainly redux isn't a controller.


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

Search: