HN user

imauld

489 karma

github.com/kylie-a

Posts3
Comments266
View on HN

All data entered in to Google sheets becomes property of Google. Cross referencing the data in your sheets with the data it collects from its other various spy programs is probably trivial for Google.

You're just skipping the app and handing it directly to the ad company.

Do a simple app in each one and see which one you like best. Something like a todo API or something like ls, cat, or grep. Doesn't have to be perfect or anything just enough for you to get a feel for the language. Preferably something with dependencies outside the stdlib since managing dependancies is something you'll have to do anyway so you may as well see how it is before you get a bunch of them.

k8s is ready. If your company is just starting up it's probably not ready for k8s.

Unless you're a PaaS company with a large SRE or Ops team off the bat you likely own't have the resources to maintain a k8s cluster. It's a great piece of tech but it's quite complex and has a decent amount of overhead. So unless you happen to have an expert already on your team or your already have a bunch of services it's probably not worth the effort.

Show HN: Wat 8 years ago

I mean:

    import pdb; pdb.set_trace()
is totally a thing. And ipdb is even better.

I feel like it requires a full-time devops engineer to create and manage all of it.

It does.

Kubernetes is a great piece of tech but it is pretty complicated and does add a fair amount of overhead on top of whatever operational concerns you application already has. If you don't have anyone that knows how to build and manage a cluster going to production with it would be extremely risky IMO.

I would recommend trying GKE, Google's managed k8s service, in staging/dev before even considering it as a serious path forward. If you are married to AWS or just don't want to use GCP then kops would be your best bet. I have friends working with EKS, AWS' managed k8s service, and it doesn't sound anywhere near as ready as GKE or as flexible as doing it yourself, frankly it sounds like a real pain. I haven't used k8s on Azure but I have heard that it's pretty good.

I also don't generally recommend deploying a new application as decomposed services either. Unless you have done this a bunch of time it will probably save you a bunch of time to just do it as a monolith and deploy it to standard cloud VM's or on-prem servers. Also be aware that Docker and by extension k8s are not the best way to run stateful applications. It can be done but it is definitely more work to get a k8s based DB working the same way as a non-k8s DB in terms of data retention. I imagine a complex application will need some kind of data store so even if you go with k8s you may still end up with non-k8s instances for you data.

k8s is great but it's overhead con easily outweigh it's benefits if you don't have a someone who can manage it. Start simple if you can and work from there.

For 90% of applications Django has everything they will need from an application framework and is fairly easy to manage.

If you're in the 10% yeah it can be a pain in the butt. However it's not impossible or even particularly difficult to migrate to something else.

They are OCD. Not only do they need to know the how, but they need to understand why...and they won't stop until they have figured out the why. This helps in many situations from understanding standards, debugging odd bugs, selecting a good stack.

This isn't Obsessive Compulsive Disorder it's being thorough or knowledgable. No need to further the misuse of this term here.

Depending on where your office is, it could be.

My last company was in an office park in the middle of no where and I don't drive. There were no stores within walking distance either. So if I felt like having a snack or something to drink that wasn't water I'd be SOL. So it was nice that we had snacks and drinks available and made working in such a remote spot much more tolerable.

Companies think devs want macbooks. I see it advertised in job posts all the time, "New Mac books." Most devs I know either hate them (myself included) or don't really care. Most of the ones that hate them are running Ubuntu/Arch in Parallels or some other VM. I do most of my stuff in Docker containers.

I would love to be running Linux on it but the IT department in most places I've heard of won't let you replace OSX. Places that also offer Windows laptops for devs won't let you put Ubuntu on it either.

So I use my MBP with it's stupid emoji bar and an escape button that can crash at work and my System76 laptop at home/everywhere else.

Those things still require a either a data plan or a phone with a browser/email client. MMS (thanks for the correction) is familiar and every phone made in recent history can use it with no login, sign up or password.

My father has an email account solely because an Android phone makes you get one. He definitely doesn't know the password and I wouldn't be surprised if he didn't know the address either. However he is very comfortable taking pictures and attaching them to text messages.

He can easily save a contact in his phone on his own. I or my brothers would have to help him set up a bookmark in a browser. Now my father may be somewhat of a Luddite but keeping the barrier really low for family members who aren't texh savvy is a good idea for this.

And as far as quality I can almost guarantee my grandma doesn't care what is in the pictures or how blurry they are. She is going to care that I am sending her something. That's the important part not HD images.

Because it's a platform agnostic way of sending images.

IMO this is actually a really good decision given the purpose of the service. A lot of my older family members that I will likely invite to my new account (great idea btw) are familiar with sending pictures through SMS and don't really use any other messaging apps or many apps at all, if their phone even supports apps. Believe it or not many older people and some younger people still rock low powered phones with little or no data plan. However most if not all phones made within the last decade can send SMS messages and more than likely are on a plan with free texting.

Why should I need to download another app that is a glorified REST client when SMS does the job perfectly well?

Search and recommendation services are definitely an example of things that do actually benefit greatly from more data. If you're building something like that then you will almost definitely benefit form more data. However, it might still be possible to generate music recommendations for a user based only on their usage patterns in their local music player. I'm not an expert in that area but I imagine it could be done.

Good luck getting users to adopt your software, though, regardless of how privacy-conscious they say they are.

It would probably be difficult mostly because we have trained users that an app isn't useful unless you can sync it to all your devices. We are always going on about how much better things are once you can connect them to everything else on the planet. We've sold users on the idea that they need to be connected all them time and we need to know everything that they do so we can "improve their experience" which for most things means "show you ads."

I'm not knocking webapps in general. I make them all the time. Some of my favorite things are webapps. I'm writing this comment on a webapp. I just also believe that not everything needs to be a webapp and have a constant connection to some server telling it about everything I'm doing.