Hacker News new | past | comments | ask | show | jobs | submit | wanderr's comments login

Is there a bank you recommend? Mostly I use online banks but every now and then you just need to go to a physical bank. I am a bit nomadic so one with branches all over the country would be good, although I know those are the most likely to be terrible


Most credit unions participate in the credit union shared branching network, so I recommend joining your local credit union of choice. You can then go into the branches of several other credit unions to do most banking needs.

The caveat is if there's a major problem, like here, then you'd need to deal directly with your home credit union.


Oh wow, I had never heard of that. I already have a CU on the other side of the country that I still use for loans because they've always had the lowest rates. I'll have to see if they participate.


Does anybody remember Eudora? Not the Thunderbird version, the one before that. It was fast as hell with cool shortcuts (eg Alt-clicking on from groups all the emails from that sender) and therefore super easy to find stuff and organize your email even if you had way too much of it. My M1 MBP is probably 2000x faster than last computer I had running Eudora, but modern email is still slower and clunkier. A web based email service that is blazing fast and makes sorting/filtering/searching my email easy is something I would be happy to pay for.

Another email service I want would be one that I have to authorize the sender before their mail gets into my inbox even if it's not classified as spam. Sure, that email can be routed to some dumping ground so I can sift through it if an expected message is missing, but by default nothing goes to my inbox unless I've routed the sender there. And when I "accept" a sender it should be trivially easy to route them to any mailbox or make a new one. And it should be trivial to manage those routing rules later. All this is already possible with existing services, but enough of a pain that I don't maintain it.

The last thing is a tough one: a way to port my existing email into the system and a guarantee that I won't lose my email if you shut down in a few years. Trying other email providers is not worth it if I won't be able to find anything from the past and I might be at risk of losing them in the future.


IIRC, they did not even bother to align the dates when comparing hashtags, i.e. this includes many instagram posts from before TikTok existed.


Ponta De Ferraria was such a unique experience. Clinging tightly to the chains/ropes crossing the channel waiting for a wave to come in. The water coming in from the open ocean is so cold. Just when it starts to feel like you're about the freeze to death (I am a wimp when it comes to the cold), the incredibly hot water which has been heated by the spring comes rushing over you. And just when you're about to overcook, it stops. Repeated over and over again. Very invigorating. I imagine it's kind of like alternating between a cold plunge and hot plunge, except I can never force myself to get into a cold plunge.

And if you are on the island anyway, there are dozens of other natural hot springs worth visiting too.


I hate this for developers. I got to experience this first hand because I had a boss who thought like you. Developers generally need to run a bunch of resource intensive tools to build the application in the first place, so an underpowered system will already be choking. It means their app will feel slow no matter what. So then when they run it and it's slow, they will shrug and say it's just slow because their system is slow.

There might be a case for specifically running testing on a slower machine, though.


I think it's reasonable to have a separate machine to do building on. You can include a push to the target in the build script, or use network mounts or something. Remote debugging is a thing, if you need to use a debugger but don't have the resources to debug on the target. But I disagree with your basic assumption that

> It means their app will feel slow no matter what.

If you can make it feel fast or at least responsive on your underpowered machine, it should feel super fast on everything else. Even today's slowest machines can run some things fast. It does depend a bit on your market though; it might not be worth the effort, but there's a lot of applications out there that could use some speed.


Once you’ve got Node, docker, Postgres, redis, an IDE, etc running, the system is out of memory and already chugging before your actual app even opens.


Run all that stuff on a different machine than you run the app on. Unless the app includes all that stuff.


It's massively easier to just give someone a macbook that actually works properly and runs everything you need than to hand out people plastic chromebooks and mess around with remote development environments. Then if required, hire some testers to click around on cheap hardware. But realistically, the users on 2010 laptops aren't the ones paying the companies bills so no one really wants to spend money on them.


Docker is slow enough without giving me crippled hardware.


> It means their app will feel slow no matter what.

How so? Do the heavy tools need to run alongside the app? Are you thinking of something like Android emulator? For that scenario, keep the beastly workstation, but switch to a $150 phone.


Actually having to develop (browser, IDE, compilers, etc) on a slow machine is pointless torture, but I do see the value in the app that you're building running in a resource constrained VM or equivalent. That way your dev experience is crisp, but you get a more realistic sense of how your application functions for the end user.


I think its reasonable to say anyone evolved in the product should regularly use the end product on low end hardware. I wouldn't expect devs to run full development environments on low end hardware unless they themselves are building dev tools.


Don't forget that development tools are also comically slow and bloated.


Developers generally need to run a bunch of resource intensive tools to build the application in the first place, so an underpowered system will already be choking.

Straw man. Of course, if you crank that knob to the extreme bad things happen.

There might be a case for specifically running testing on a slower machine, though.

Agreed here. I think the optimal is for devs to be able to do intensive operations on a fast machine, dogfood for most of their time on a average machine, then test on a somewhat slow one.


I recently switched an old PHP project from sending me emails directly via SMTP to using mailgun. At first I tried to use their SDK. It pulled in like a dozen dependencies. I gave up on that idea and replaced it with a simple curl call.


I had very similar experience with npm. Especially when you need to merge all the security updates for the sdk and all their dependencies. I also prefer interacting with the api, if it is straightforward.


Find a 4 hour block of time that works well for folks in the various locations you will be collaborating with and make yourself available during that time. I work with folks on the east coast and west coast. I was able to live in Hawaii and stick to the sleep schedule I had on the west coast, that is, waking up super early Hawaii time, having all my meetings in the morning and then having flexibility the rest of the day. That was great because I could take advantage of the copious daylight to explore and then finish work in the evening. On the east coast my collaboration time was on the late side so I could use the morning daylight and then jump into meetings and work later. In my experience it generally isn't that hard to fit collaboration time into those hours and then occasionally flex for exceptional circumstances and responding to async questions on slack to keep others unblocked.


how was Hawaii?


This article seems to be more making the case that features are technical debt, sort of. And that's a valid point too. But it is so so easy for useless code to accumulate. At every company where I've worked as an engineer, I've ended up deleting lots and lots of code, far more than I ever write. Like, half of the codebase. Largely by applying static analysis to find code that clearly never worked, the confirming that it's not used (which is usually obvious or we'd be seeing crashes). Often times it's sad to see how long that code was maintained, with engineers wasting effort on migrating it as things changed, without ever questioning whether it's even needed.


We built Grooveshark with an extremely small team and grew it to a massive scale. We re built Grooveshark multiple times (moving from flash-based to HTML5, several major design overhauls, adding collaborative listening, etc). It absolutely boggles my mind how big Spotify is and how stagnant the product is.


Not just stagnant, but clearly getting worse.

- 95% of my auto-suggested/generated playlists I get for the last ~year are now the same ~200-400 or so tracks rearranged in different orders.

- Half of these tracks are not artists I ever intentionally picked myself, and in fact they are tracks and artists I don't like. So I have to essentially skip half the tracks which are suggested - Spotify doesn't seem to take into account that I keep skipping certain tracks/artists - it suggest and keeps recommending them over and over again. I've gotten to the point where I have to block entire artists in settings just to have reasonable playlist suggestions (which still suck).

- The mobile (android) and webos apps seem to be getting more and more buggy every update. From pause/play breaking and skipping to the next song, to the webos app bugging out when attempting to control using phone, to the apps randomly crashing like once a week, etc.

All of these problems didn't exist or were far less common just a few years ago.


I don’t understand the appeal of Spotify. Back when it first came to the U.S. there were a few competing services and I thought Spotify was towards the bottom in terms of recommendations. Pandora was so much better, although all they had was a radio product. Even Rhapsody, from the detestable Real Networks, had a better product than Spotify in my opinion. These days, I would rather use Apple or YouTube.


That's an interesting point regarding suggestions. I wonder if they are having a massive drop in user engagement as the user base has matured.

As in, anecdotally, all my friends and I just talk about using the radio from a track or another playlist, as opposed to curating playlists ourselves.

The golden egg that Spotify was sitting on (user-driven curation and favourites across a huge userbase) may be slowly evaporating.


It's not that stagnant, they have time to make the product worse imo. Their recent UX changes broke my weekly workflow, they buried the discover playlists behind three clicks and scroll, and they seem to have changed the algo so that it recycles the same songs over and over again (though my listening patterns have changed a bit since a recent addition to the family). Playlists are harder to create. And heaven forbid the thing you want to listen to is listed at the top of the iphone app when you open it, because they're going to refresh the list in 3... 2... 1... oh it's gone.

Sorry for the rant. I love Spotify. Nearly all of recorded music for one low low price. I wish they would realize that their apps are utilities, not social, and stop optimizing for engagement.

All I want to do is change the bluetooth settings back to my phone and all I see is "start a remote group session!" No thank you, get your sharing features out of my face.


Same as Twitter before Musk.

Basically the meme of Javascript / React devs making everything complicated is amplified at really large scale in a lot of these companies and there is a lot of truth to this. "Frontend engineering" is basically a bullshit jobs program masquerading as real engineering work and costing company billions in time and money.

Like Spotify had this whole team dedicated to just the back and forward buttons. Whole team for 2 buttons.

I wish more companies tried to be like Valve who are more efficient than FAANG or any other tech company.


Do you have the impression the Twitter web application has been improving since Musk took over?

Also, the Steam client has to be one of the most stagnant applications I ever had the pleasure of using, not sure that makes Valve super efficient.


> Also, the Steam client has to be one of the most stagnant applications I ever had the pleasure of using, not sure that makes Valve super efficient.

If said software is fit for purpose already, why the need to induce frivolous change for the sake of changes themselves? If permanent stagnancy is bad, perpetual change is equally bad IMHO.


In my experience Steam is slow and crashes often. I don’t generally care about UI updates (which Steam does actually have)


Every popular webapp can be easily made with PHP and hosted in a bedroom, prove me wrong. We don't even need backend solutions like containers or kubernetes, companies have definitely wasted time investigating these technologies and putting money into them.


We definitely don't need containers or kubernetes. Netflix wasted so much time and energy with the whole microservices nonsense while pornhub serves more video in more locations purely using PHP servers.


Kubernetes is supposed to make these things easier, and it very much can (and do for many). Containers are great, microservices on the other hand just seems like a way to decouple things so nothing can be verified AOT


Grooveshark was amazing


I used to use Grooveshark back in the days, while it had it's own warts it was amazing for its time. I was sad to see it go when it went. I'm mainly using SoundCloud for my techno needs these days as Spotify can't seem to recommend me new music.


That confused me as well, I never made the connection to 0 and 1 until someone told me


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

Search: