r00k

Tuple is a macOS app for doing remote pair programming. It's faster and higher quality than things like Zoom and Slack Calls, and our customers love it.

The app is built on WebRTC, and we want to hire an expert to help us add support for calls with 4+ people. Later, you'll help reduce our latency, improve perf, and build out our monitoring infrastructure.

We're bootstrapped, highly profitable, and growing revenue (but not headcount) quickly. Our team is 4 full-timers (3 of which are cofounders), and 2 part-timers.

More details, and a link to the short application form can be found here: https://tuple.app/webrtc-expert-job

Thanks!

Tuple is a macOS app for doing remote pair programming.

We're growing very quickly for a bootstrapped company, and could really use the help of an experienced engineer with (ideally) macOS experience.

We're still just 3 cofounders, so you'd be our first engineering hire. You'd be part-time/contract at first, but it could expand to full-time later.

Full job description: https://tuple.app/part-time-engineer-job

Thanks :)

"Your First Pairing Session" – https://tuple.app/pair-programming-guide/your-first-pairing-...

I wrote about my specific recommendations here: https://robots.thoughtbot.com/you-should-take-a-codecation.

Do you know that for a fact? You probably meant "I think a mobile app might be better."

I'm one of the aforementioned creators of Trailmix. I am indeed a thoughtbotter, but Chris is actually a GitHubber.

So far, our $3.99/month price seems to be working out well. We get the occasional comment that the price is too high, but people are still signing up at a steady clip (~5/day).

I'm glad to hear that you (eventually?) plan on charging for your site. While it doesn't cost much to host something like this, the opportunity cost of time spent on support and maintenance is real. I'd be uncomfortable using a free, freemium, or "pay what you want" model given that. It's probably fine for your first year, but as your free user-base grows and your passion fades, I imagine it's tempting to shut it down. After all, the OhLife guys used a freemium model too.

Anyway, best of luck to all of us!

Our site: https://www.trailmix.life

The code: https://github.com/codecation/trailmix

I don't want to lose my journaling habit, so I looked into every recommended replacement in this thread. Sadly, I found each one to lack the relentless simplicity of OhLife.

Since I couldn't find what I wanted, I rolled up my sleeves with a fellow developer and started building.

Our plan is to add exactly one feature to OhLife: non-optional paid plans. We hope this means our service won't just disappear due to lack of financial stability.

If you'd like to know when we launch, you can drop your email on this simple page: http://notify.trailmix.life/.

That sounds like a shockingly-high amount of employees.

It numbers your current line as 0, and counts up and down from there. It makes it very easy to see that you need to delete the next 5 lines, or move up 10 lines without doing any math.

As for your mouse comment, I don't think you can compare the speed with which an experienced vim user gets their cursor where they want it to the catastrophic cache miss of removing your hand from the comfort of the home row, grabbing the mouse, moving it where you want, clicking it, and moving your hand back to the keyboard. The mere thought makes me shudder :)

The link you provided doesn't accomplish the same thing as their product.

Your link is just a read-only view of your calendar (unless I've missed something). The real utility comes when people can actually schedule something on your calendar without your help.

I've been wishing for exactly this recently, and am excited to try the app.

Also, since I'd use this for work (saving me real time) on a company credit card, $10/month is without question a completely negligible amount.

In summary: I disagree with everything you've said. :)

Isn't it time to look for a better job?

Can I make a suggestion? Make your email capture form immediately visible and give it equal emphasis with the video.

Don't let intrigued people leave without giving you a way to contact them later. People who offer their email address are your biggest fans, and having that information will be valuable to you almost instantly.

Makers of Twitter clients were eventually reminded of this fact in a rather painful way.

If everyone starts including a 2 minute intro, then it won't make you stand out anymore, and you'll need to take a different tack.

The reason I sent Chad that video was to demonstrate passion. Doing what everyone else does doesn't accomplish that.

I recommend taking this as an illustrative example, not a step-by-step guide.

They're the most profitable company in the world. What pressure are they under?

That said, the fact that GuestBookEntry doesn't have validation as a concern does make it simpler.

I might refactor to something like this if a particular model had extremely complicated validation logic, but wouldn't ever do this as a first pass.

For example, I use factories to create test objects that are complicated to set up (using a gem named factory_girl, actually).

Also, in Ruby, every class is a factory for its own instances. If I define a class called User, I can assign the class object User to a variable:

factory = User

Then I can call

factory.new

and receive a new User instance.

As for DI, it's not wrong, nor is it unidiomatic. Plenty of folks in the community use it, and often.

A commenter elsewhere in this thread says that DI is unnecessary in Ruby because you can just reopen or redefine a class whenever you want. That's technically true, but isn't a good practice, as it can lead to some rather rapid foot shootery.

If you want to swap in different-behaving dependencies, DI is a straightforward choice. Reopening an existing class and mangling it can cause very confusing behavior, and is generally avoided by experienced Rubyists.

Hey there Mr. Strawman.

I write mostly Ruby, and I use dependency injection, factories, and decorators liberally. There's nothing in Ruby that makes these any harder than they are in Java (in fact, I'd argue they're easier.)

Two years ago, when this piece was written, the author had more of a point: some people rejected anything that reminded them of Java out of hand, including design patterns.

These days, I'd argue that interest in classic OO design ideas is experiencing a massive resurgence in the Ruby world.

I'd like to preface this comment by saying that I'm a huge fan of your work. You've personally helped me a ton.

That said, I must ask what made you choose video as the medium for this content. Frankly, you're a much stronger writer than on-camera personality.

Even beyond congeniality, why is five hours of video at 150wpm superior to a medium-length ebook I can read at 800wpm?

Thanks!

Staying on the home-row vs having to move your hand over and back constantly affects your speed and accuracy in a big way.

Here's an easy way to switch: never, ever use the arrow keys to move the cursor again. Done!

To the average user, sure; the text box is more friendly.

But that's not the point with vim. At all. Vim's design goals are speed and efficiency. To date, non-modal editors haven't come anywhere near vim in that regard.

Their homepage says this "DataGenetics is a technology consultancy specializing in unlocking the value stored in large databases. Using a variety of techniques we can mine the trends in your data to help you maximize your marketing and advertising campaigns."

Damn.

Yet another group of smart folks focused on more-effective advertising.