HN user

jibberia

64 karma
Posts2
Comments36
View on HN

Hypno | iOS, Full Stack Web, Creative Software Engineers | Fulltime | Onsite | Brooklyn, NY or Los Angeles, CA | hypno.cam

We build technology for events, retail installations, and experiential marketing where the common thread is the camera. We scale from small events using our "off-the-shelf" tech to giant events with hardware fabrication, programmed lighting, high-end cameras, robotics, projection, etc.

Here is a list of our current job postings: https://grnh.se/22fb2d282 (disclosure: this link tracks applicants so I may receive a small bonus for making a referral)

HN people will be interested in the iOS, Full Stack, and Creative Coder roles. We're also interested in people with Android skills. Contact kevin@hypno.cam with any questions!

I have a new favorite sentence for the ones I've heard lately: "There's a world where there's a solve for that ask."

"There's a world where..." replaces "Imagine if..." or "It's possible that...", and I think it's actually a neat way of presenting an idea -- if used very sparingly.

"Solve" and "ask", in this context, replace the words "solution" and "request". I'm not sure how people started abusing these words, but it's pervasive in my industry. I suspect it follows the recent trend of "nouning" verbs (a reverse-Calvin thing to do: https://i.imgur.com/l5AC4qG.jpg) like using "gift" as an action verb ("they gifted me a calendar"). I can understand that because there isn't an equivalent alternative word in English. We could just say "give", but it doesn't have the same meaning as "give as a gift". "Solve" and "ask" are nouns that already have suitable traditional words to use instead!

A friend of mine has two kids <= 5 years old who have grown up using Netflix. They saw cable TV for the first time when visiting a relative for the holidays, and he was worried that they seemed to have a lot of trouble distinguishing ads from content.

I suppose it's a good thing to teach. How else are kids supposed to know? How do kids who grew up with broadcast and cable ads learn to tell them apart?

I use rebase because I often have long-running feature branches (maybe for a couple of weeks) and I want to keep up with changes on master. When I was new to git, I used to merge master into feature branches to achieve the same effect, but my pull requests were littered with commits already made to master.

Is there a better way to keep feature branches updated with changes on master?

I'm interested in replacing my 27" 2560x1440 display with something of a higher resolution and larger, but I haven't found anything I like. You can get 30" 2560x1600 displays, but while I like the taller aspect ratio, there isn't that much more usable space and the DPI is too low. It's old tech, I had one 10+ years ago. There are also the new 34" widescreens, optionally curved, which at 3440x1440 are just wider versions of my 27". That could be neat, but I'd like to have more height to work with.

Another option is the 27" 5120x2880 LG display that Apple sells. That's like a "retina" version of my screen. I could run it at a higher effective resolution than 2560x1440 when I need more space, but this feels like a tradeoff -- my eyes aren't so great. I don't like tiny text. I'd also have to buy a newer Macbook to drive it... meh.

I'd like to get something that runs at the DPI my 27" display provides, but larger on all sides. I stare at a monitor for most of my waking hours so price isn't much of a concern, but as far as I can tell, nobody makes something like this.

I thought about two 27" displays rotated 90˚, but subpixel rendering goes away when the panel rotates and it looks horrible. I also wouldn't like a big seam down the center of my monitor.

Any tips?

I have large hands -- not exceedingly large, but I wear XL gloves. The MX Master is a bit too narrow for me. It's designed to be held between your thumb and ring/pinky fingers, with your pointer and middle fingers on the left and right buttons, and I feel cramped after using it for awhile.

I wish they made a larger size, because I really like it otherwise.

I spent an hour or so with GitLab and disliked the amount of whitespace. I shouldn't have to scroll so much to see what's in a repo.

</minor-annoyance>

I got into professional game development in the last few years and found that the state of good, modern software engineering practices in the game world is years behind, say, web engineering.

Games are still all closed source. Game engineers prefer to sell their components for a pittance (for example, on the Unity Asset Store) instead of collaborating on GitHub. They really, really hate writing tests. There's a deep reliance on manual testing. They still have a "ship" culture ("who cares about the code, as long as we ship by the deadline?"), disregarding the fact that games run live for years now. Multiple managers actively fought me on doing code reviews (I was new-ish, I wanted my code to be reviewed). I saw and worked on games that had no codified version control branching strategy. No coding standards. Multiple issue tracking systems. A pathetic grip on sharing code among projects. Four implementations of a state machine in one game. It goes on.

I'd like to think it was just my employer's problem, but from talking to people who have been in games for a long time, it's endemic to the industry.

I'm now out of the industry :)

I've got some nostalgia for Yahoo Games. Here's an anecdote I've posted elsewhere:

I was on a phone interview to be a software engineer for a web game company in ~2013. The interview went very well. At the end I asked what I'd be working on, and they said blackjack.

I said, "Didn't Yahoo solve that problem in the 90s?"

I didn't get a call back.

Agreed. I just signed up to try out GitLab and went to browse GitLab's own source code to see what they were using. First thing: Rails, clearly. Second thing: Holy crap, I have to scroll this much on my laptop to browse their project? The amount of whitespace is bonkers. A bit of googling tells me that they made this change a few months ago with GitLab 8.0, but the bug report about the whitespace seems to have been ignored.

I really like what GitLab is doing, but I also really like a powerful web-based repository browser (search tool included). Hopefully they just went a bit wild with the UI and they'll rein it in. (I also checked Preferences and they have a switch for fixed vs. fluid layout, so maybe they've been responsive to UI-change revolt in the past?)

At my company, we'd call the position the author is interviewing for "QA Lead". We subcontract QA testers, so they're not responsible for managing people beyond making sure work gets done.

I think these are great questions for QA leads, not the person who manages them.

Learn grep. If you're familiar with using a shell, it'll be the most immediately useful.

# search current and all child directories for files containing "bananas", case insensitive $ grep -ir "bananas" .

Ah, it finally happened. My company has a legacy-ish SDK that all our products are built on, and because of bad decisions in the past (like extensive use of C macros) it essentially cannot be ported to 64-bit. Luckily we're already building the replacement, but this is going to accelerate the requirement of having to migrate data from the old system to the new one.

Almost 10 years ago, I did an undergrad independent study at NYU contributing to some PhDs' Query by Humming music search engine. We used q to query a kdb full of catchy-melody time series data -- short sequences of "is this pitch higher, lower, or the same as the last?" and "is this note short, long, or medium?" (and, of course, gobs upon tons of variations as we iterated!).

I barely did any q / kdb; only made a functional and usable UI, and did some prototyping of new ideas in other languages (Java, Max/MSP, Csound). I spent some time looking into q and was thoroughly baffled. Still am. It was really, really fast, though!

As I vaguely understand and can explain it, the k/q system made it easy to do fuzzy searches and deal with missing pieces of data. If the user missed a note, or our pitch detection failed, or our source data was bad, we were still able to find matches. (Yes, I wish I'd been able to understand this more at the time. Bygones, now...)