That is fascinating - can you elaborate on what you mean by the Apps market?
15 karma · joined July 21, 2019
The most common cause of death is sulfate build-up, which can be prevented (and often reversed) with a homebrew circuit[1].
1. https://batteryuniversity.com/learn/article/sulfation_and_ho....
Building things that don't scale is often taken to the extreme where it's nothing more than a few HTML pages strung together by self-rolled crypto and javascript. This might be good for idea validation (first couple of days), but it shouldn't persist past this point.
Understanding when the inevitable problems pop up and being able to solve them in reasonable enough time not to lose your users is - to me - not a nice to have problem. It's a showstopper that will turn egg on your face problems into fatalities.
Few things I would recommend are:
* Instrumentation - You don't need to go full ELK before you find product-market fit. Hell you can log everything, and with two users you can always read all the logs. But something is key. * Up and down scripts - How long will it take you to set up a new copy of the product? Do you have to trawl bash logs and have a team meeting to find out all the configs that need to be set up? * Load-testing - Again, nothing fancy. Just put curl on a bash loop and see where the system starts to hiccup. Once you have real users with complex data on real hardware you'll wish you profiled things, even slightly. * Instrumentation - I say it again because the sheer number of systems I've found on the verge of silent failure and user frustration because the errors weren't being propagated, be it from client side to server or from the logs to an alert, is massive. With modern SPAs it's easy to think everything works when all your users see is a blank page. * Please don't roll your own crypto. Unless you're working in a language that is 2 days old you really shouldn't need to or be doing this.
In short, if you're using HPAs and Kubernetes you've gone too far. But don't choose your instance size at random, be able to set up a new instance in an hour, and have at least 60% confidence that if there is an error you will know about it.
You can pay for a tiling manager on the Mac, but it's definitely not as good as the alternative.
I'm sure Spotify and Safari and the like will work on launch day, but I'm not too sure about Postico, Disk Inventory X and others.
All of this would be fine if I trusted Apple to care about developers and niche users, but I just don't see it.
I think I'll definitely buy an ARM Mac (or an iPad) for media and other things, and will still recommend it to friends and family once they're done with the transition, if all goes well. The polish around the Mac ecosystem is still unmatched, if you color within the lines.
With Apple's history over the last few years, I don't expect the sheer amount of legacy software I use on a regular basis to be taken care of when the new architecture comes around. Under legacy I'm also including applications with a single developer that can't really go multi-architecture, applications with niche communities that Apple will take a long time (if they do) getting around to writing drivers, providing documentation and support around porting.
Now the most common rebuttal to this is either Rosetta or that this is how technology works. For Rosetta, just based on the sheer difference in instructions I don't see an easy transition here that works off the bat. IMHO Intel's compiler design also beats Apple's, and I don't see niche apps working right or complete for a long time, and I see a lot of apps being left behind.
But I do understand that this is how technology moves forward, and I think that if they can make it happen (it's still a big if in my mind but I'm aware I know very little here), it will be a big step forward. If anyone can do it today, it's probably Apple. However, I have very little doubt that the transition will be fraught with problems, especially for power users, and it's a personal choice not to live through that transition with Apple.
I'll also add that while I see the strong possibility of personal computing moving to ARM, I'm less convinced by the arguments for cloud. As I primarily develop backends and do cloud arch, I would much prefer to build as close to deploy as conveniently possible.
Now for the iPad part - and this is simply how I feel watching and living in the ecosystem for some time - I think Apple intends to turn the Macbook into the iPad, with one big happy ecosystem of apps that work on everything. While I think this is great for the general public, I'm yet to be convinced that it won't end up with a mediocre experience on everything[1] especially the Macbook. I see the value of a computer that isn't a computer (what's a computer?), but I think that (intentionally) overlooks power-users that use the computer to build things for computers and video and audio professional, to name a few.
1 - With iPad apps being available on the Mac within days of release and minimal developer intervention, I cannot see how it would not be a mediocre experience. How do you do multi-touch on a trackpad?
Again, if anyone can do it it's Apple, but I don't believe it will be an easy journey or one that's going in a direction I can join in. I do still have the option to leave, so I am.
Here's a small summary: https://hrishioa.github.io/my-home-cooked-meals/
We've found intercom to be a massive improvement in our user conversations, up from when we have a live chat button as well as when we had a direct WhatsApp/chat functionality through a page.
I'm with everyone here in how annoying chat plugins are, in fact I was so against it that I fought tooth and nail to keep it out of our product. I eventually decided i should back it up with data and decided to give it a shot.
Speaking to the users, they love it. We're short circuiting a lot of conversations about usability and "how do I do this" little things that wouldnt have even reached us otherwise.
I rub with all of this is that I think we operate in a different user space than most of the commenters here (but I may be wrong). I say this because I still have chat popups, and it actively turns me off using a product and makes the decision for me in whether I buy something (to a no).
The difference might be that our users skew older - 40s to 50s and up, and are from a very old industry with little tech penetration. Email is still the preferred mode of communication, And they don't escalate anything except complete system failures. Intercom has somehow jumped that gap and makes them talk to us more. I'm as surprised as anyone.
I'll definitely be giving it a try in my next project.
How would you say Deta is compared to Zeit or the other micro-cloud offerings out there? I've never used it.
Wait, something's slightly off with kramdown - this isn't right - 12 hours later you're recompiling to update dependencies, and your version of ruby is out of date.
This is Jekyll specific, so YMMV - but if you're like me, probably not by much.
We began as a species focused on making sick people healthy, and it's the way the entire system works. It's near impossible to get studies approved that tackle aging and proactive healthcare with drugs, as they will largely need to look at the effects on people who are healthy now, but will almost assuredly die from dementia, Alzheimer's and heart disease.
I understand why it is the way it is, but it's frustrating to see the system wait until you have heart disease in your 70s before doing something about it.
Over a million seafarers are still stuck on vessels around the world as governments refuse to let them in, and we're trying our best to bridge the gap with software.
The problem with using curl and wget directly is encountering websites that generate a one-time, non resumable link which they then communicate to the browser. In most of these cases, it requires a fair bit of reverse engineering and mocking requests to get the link in bash, in an unspoiled state so curl can download it.
The best option I've found at the moment is JDownloader2. It's been the most reliable downloader for complex files while being simple enough to use with its integrations.
> Context: This is a highlighted summary generated with an app I built to help myself approach all the drier HN links I was opening. I appreciate any feedback from the HN community on this project!
Nicely done! Small suggestion I have is to add the expand functionality to tapping on the passage. It feels more natural and doesn't currently do anything.
Another interesting thing to do is instead of giving up your phone, remove all the apps you usually use and commit for a week to only using apps and websites you've never used before. Similar effect.
1. A large number of countries have agencies that will aggregate freelancers and take on large jobs. I'm not suggesting large players in the size of TCS or SAP, but smaller shops that hire out devs. It's a good place to start to get contacts into companies you'd like to work at, then move to a direct position there. Most countries make anti-poaching clauses practically unenforceable, especially if the candidate is the one approaching the company.
2. This is higher risk higher reward, but building micro-B2C/SaaS for a different market then launching on sites like Product hunt have the opportunity to bring in revenue. This is only if you're cut out for it.
Can't say much more without details, but I wish you luck in your search!
Most of the time, as long as the hire is above a certain skill level, the bottleneck is absolutely the communication bandwidth between you and them. If they don't completely understand things or you don't understand them, the number of round trips increases. Add to a general sheepishness when presented with American English and slang, as well as certain cultural tendencies, and you encounter a lot of hires who will say yes (especially from India and Vietnam) when they don't understand. This is a big problem.
I've also seen the efficient market at work, but on a level up from the programmers themselves. In a lot of cases, programmers from developing countries are hired out by agencies who will charge a lot closer to market while paying them less. This might cause a lot of the disparities in the data looked at by the author, and in any data where salaries are compared directly.