HN user

farski

81 karma
Posts9
Comments40
View on HN

This was my plan for my dad's PC, but, while he uses an iPad he uses for the vast majority of his browsing/email/etc, he uses his PC to do his taxes and the taxes of quite a few other people. TurboTax is dropping support for Windows 10 for next year's edition. Based on everything I've seen, it simply won't run (or that's how they are communicating it). So now I need to replace my dad's 3 or 4 year old computer only because of TPM. TT is saying they're doing this because Windows 10 support is ending, which obviously it isn't. Bad decision making on both ends, but the outcome is the same: I have to basically get rid of a very nice computer.

I'm holding out as long as possible, hoping that reason re-enters the game, but I'm not holding my breath.

I agree with other commenters. The pitch didn't do a great job of explaining what problem this solves, so I went to the demo video to find the answer. There's no logging problem big enough in my life to require a tool that takes 48 minutes to explain, so that's when you lost me completely. Even the console demo did more harm than good. It provided no real-world examples of logging (complex objects, multi-stage processes, etc), and some of the fancy bits were worse than vanilla console.log (e.g., the "debug" badge that is dark gray text on a dark gray background).

As others have said, doing maintenance before things get to the point of needing repair is also worthwhile. When I buy something that I want to last a while, I make sure to read the manual and also do some additional research to identify any scheduled maintenance that should be done, and I create a reminder in my Todo app to stay on top of it. That includes big things like car maintenance, and small things, like laundering a shower curtain before it get so stained and gross it can't be cleaned.

We work with lots of podcasts that were created in a time when Feedburner was standard operating procedure. We were already seeing reliability issues with Feedburner on those feeds this week (intermittent 500s), but if they really broke or removed custom domains, it's going to be a long weekend for our teams.

Could you say more about Raycast vs Alfred? I've got lots of customizations built into Alfred, so switching always feels like a big lift and I use it so much it would be a major disruption to so many workflows. But Raycast does look very nice, so I often think about making the switch.

That's a great clip to link to because 30 seconds later Tristan says "I don't want to be responsible for you guys beaning it off the side of a hill because you were trying to go too quick," which obviously was him walking back Ben's recommendation a bit because even he thinks it's a safety issue to look at a map while descending hairpins as a tourist.

I tend to update my Karoo pretty quickly, but I have never seen any indication that it would force an update, so I think people could stick with last week's version for as long as they want.

That being said, this week's update that removed Di2 also added some nice location-based auto lap features, which are way more useful than an icon telling me which gear I'm in, which I already know, so I updated.

There are a bunch of features on Karoo that will show or indicate turns regardless of which screen you're on. As jfengel said, if you're going 50mph you should know where you're going and not looking at your computer. The other things being removed (battery level, gear indicator, shift mode) represent no realistic safety concerns.

I'm annoyed that I'm losing these features, too, but they are all firmly in the nice-to-have category. Just like bike computers in their entirety.

I found it very hard to figure out how to choose content, since I don't personally know anyone using the app yet. I like the concept, and I don't think I want an algorithm as a lunachpad, but Flickr always had groups/categories/etc that helped with discovery. I was surprised Glass didn't have anything similar to that. It felt like a huge hurdle to get into the app.

The initial experience to get AWS icons loaded was a little strange. I saw all the Azure icons loaded by default, and when I searched for something like "S3" I got a message that said "No records found. Did you try adjusting your icon preferences from the 'user preferences and settings' menu?", but I couldn't find that menu.

I eventually saw the "Add/remove icons" option at the bottom of the screen, and figured out how to turn on the AWS icons, but then I got stuck in that menu. I had to refresh the page to get out of it.

Any time I need to convert a date to or from Unix epoch timestamps, I find something on Google and I’m pretty disappointed with the experience. Every single option on the first page of results uses six or more form fields to enter the date and time, and they use discrete forms to go in each direction. Even the one available on Omni Calculator isn’t so great.

And spending a lot of my day in JavaScript, I always have chop off some digits by hand before any of these tools work, since they don’t detect when values are in milliseconds.

I made epoch.place [1] to try to modernize things a bit. It’s open source [2], and features include:

- Modern natural language date parsing - Automatic detection of Unix timestamps in seconds and milliseconds, with overrides - Multiple output formats always available - Click-to-copy any resulting values - Linkable results - Realtime output of the current time in all formats, and the delta between your input and now

Simple, straightforward, no frills. The page should load in about a tenth of a second, so you can get in and get out.

It uses Chrono [3] for parsing, and runs entirely client side with no cookies, tracking, ads, or dependencies (other than Chrono which is being loaded from jsDelivr).

Mobile support is still a WIP, but I hope this app makes the task of dealing with timestamps a little bit easier.

[1] https://epoch.place/

[2] https://github.com/farski/epoch.place

[3] https://github.com/wanasit/chrono

Hi all! Botzee is an app that lets you play a text-based dice game right in Slack. If you’re familiar with Yahtzee you should pick it up really quick, and even if you aren’t it’s an easy game to learn.

It has single player, multiplayer, and some simple AI bots. I also just recently added an MMO variant, which allows all players to compete in a single, giant world-wide game (in a completely privacy-conscious way).

With more people spending all day isolated, I hope it can be a source of fun and social time for teams, groups of friends, families, etc. I’ve gotten a few really nice notes from folks lately about how it’s been a welcome distraction from the daily grind. The app does include a few donation buttons, but it is truly free to play, and I have no expectations of making money off it. I’m sharing it simply because I think it’s fun and I’m happy with where it’s at. I make and maintain it entirely so I can play with my friends, but I hope others can take advantage of it as well.

For those interested in the architecture, it’s a fairly standard serverless app running on AWS. All requests go through API Gateway and are handled by a single monolithic Lambda function, and it uses DynamoDB for data storage. The total cost for running it last month was 17 cents. As you would expect, it handles the periodic, bursty nature of this kind of app very well. It’s been fun project to pick away at over the last few years. I often use it to test new AWS features before bringing them into projects at work, and I quite like the Slack API and app platform, so coming up with ways to integrate new features from there is always an interesting exercise.

I hope you enjoy it, stay safe out there!

PS. If you’re looking for a way to spice up your Botzee games, consider a battle royale style tournament, where the lowest scoring player is eliminated each game, until a champion is crowned!

I have an encrypted sparse bundle disk image (.dmg) that I use to keep all documents like that: tax, bank and investment statements, insurance policies, etc.

It lives on an external drive that is backed up to Backblaze. Since it changes fairly infrequently, I'll also manually drop copies of it on other clouds occasionally.

I switched to FastMail several years ago. I had been hosting my email on Dreamhost, which was "just okay" in term of what they offered for email, but it was costing me about as much for shared hosting, XMPP, email, mysql, etc per year as FastMail was going to be just for email. So, like you, to me it felt expensive at the time. It took me a while to pull the trigger.

The things that made eventually got me to make the switch were:

- I realized email is basically a utility for me. So while I'm happy to spend $30/mo on cell phone, $60 on my home ISP, etc, it was kind of crazy to think I wouldn't spend $4/mo on email - FastMail had great reviews. Pretty much every time I did research to answer "is this really the best choice?" the answer was always yes - They seem to really care about IMAP as an idea. If you read through their blog, they do a lot of work to make sure IMAP is a great open standard for communication. That means their support for the protocol is always getting better, and they're improving OSS projects related to IMAP that they use.

Also they keep getting better. Aside from dropping XMPP support (which I can understand, though I have yet to find a suitable replacement for), their service offerings have gotten better since I signed up. Obviously email is email, but there are many little things that have received constant updates since I joined (better admin dashboard, better mail/contact/cal push support for iOS, more sensible billing options)

I could go on, but paying whatever I pay for FastMail service has definitely gone from "ehh do I really want to pay that much for email?" to me really liking supporting them as a company. If they were to increase prices a reasonable amount at some point, I probably wouldn't hesitate paying it.

I don't think Slack is perfect, but a few of your points don't line up with how I've seen Slack used with many different groups.

In business (and outside of business), anyone can be interrupted at any time regardless of Slack. If people are expecting immediate replies 100% of the time, that's a cultural thing, not a Slack thing. It's very common to send a message to someone who's on vacation and get a response a week later, just like with email. Of course _more_ conversation happens in real time on Slack as compared to email, but that's kind of the point. They are fundamentally different types of conversations. The various notification options that slack provides (per-channel per-device type, global pattern notifications, etc) mean you can pretty much avoid being interrupted except when you really want to be. People who get mad that you don't respond to Slacks right away are the same people who get mad that you don't respond to emails right away.

Three notifications states is pretty much the same or better than any other sort of emergency communication. Pagers, text alerts, emails, etc have essentially the same degree of distinction between messages, with the reader having to determine severity from context. A text message from GrubHub is less important to me than one from PagerDuty, but my text messaging system doesn't know that. So it's true that if you had a single channel in slack where people were talking about donuts and server fires you wouldn't be able to tell the difference. But you shouldn't have a channel where people are talking about donuts and server fires.

Slack makes it very clear that channels should be treated as disposable. I agree that they shouldn't be spun up and down as quickly as email subjects/threads, but again we're talking about different forms of communication. Slack is, by definition, _chat_, which means there's a lot more of if than email. For the most part chat is meant to reach some end point, whereas email _is_ the end point. It's rarely valuable to go back and read through a chat transcript on some topic, even if it's nicely delineated. Are there extremely verbose email threads? Yes, but they are equally as useless after the fact.

I think part of the Slack backlash confuses me, because it really just moved where this type of conversation was happening. Across every Slack team I see stats for, the ratio of private to public chats is huge, and private chat was happening before Slack (in IM, Gooogle Chat, etc). And I don't think the way those messages are being treat, or the expectation for replies, is really any different. The new chat that's happening tends to be very low volume.