metaloha

Seconded. No matter how good you feel you are in this field, chances are great that 90% of your work is based on negative input. Relatively few developers get to work on green-field projects with any frequency, and even those can (and will) quickly become slog-fests of bug patching. The more management overhead there is in the company, the faster this happens (IME).

If you can remap this in your mind to be expressed as improving negative experiences, then maybe it will seem better emotionally :)

Fascism and narcissism seem like things that aren't getting talked about enough (because if they were, we'd be seeing less of it, not more).

I'm also a JetBrains user of many years and several of their IDEs. I don't find Fleet (the VS Code clone, I think) really useful myself (and I have never liked VS Code or Atom or any of the other clones or Sublime-likes), but IntelliJ and Rider seem fine.

Animating dimensions on an element with an `auto` height or width comes up at least every second or third project I do. Having this work as expected without any hacks or extra JS would be AWESOME.

I don't know but it's a fantastic idea I think. I could see myself setting up an Angular course this way

Think of `em` like a percentage of the current font size. So if you have a `div` with a font size of 16px, then a `p` tag within that with a font size of `1em` will be 16px. If the `p` tag is `0.8em`, then the font size will be 12.8px (or 80% of the current font size).

  + html = 16px
    |
    + div = 1rem (equivalent to 16px)
      |
      + p = 0.8em (equivalent to 80% of 1rem, or 16 \* 0.8, or 12.8px)
        |
        + small = 0.8em (equivalent to 80% of 0.8em, or 12.8 \* 0.8, or 10.24px)
        + span = 0.8rem (equivalent to 80% of 1rem, or 16 \* 0.8, or 12.8px)

So by changing the font size of your `div`, all child elements that use `em` will automatically re-render as well (but child elements using `rem` won't resize, because their size isn't affected unless the `html` font size is changed).

The "current font size" is determined by lookup up the hierarchy to the nearest parent element with a specified font size, ending with the `html` element which will reflect the browser's default font size if nothing else has been set.

This would seem like basic knowledge that anyone responsible for a web server would know to handle. At the absolute and very least, an `.htaccess` file would help.

You'll likely need to get some custom development done to avoid ongoing subscription costs in favor of a larger up-front cost. I've done this type of thing a few times in my career and have found that while platforms like Vimeo and Streamable can be nice and cost effective early on, it's probably cheaper long-term to have something bespoke created.

Fail :( I sign up, receive the code and put it in, then it doesn't let me log in - "Incorrect username or password" message.

This seems stupid to me. Maybe I just don't get Web3...

I just need you to fix the typo on the site - "lightening" and "lightning" are really different things.

I don't know that Kubernetes and Docker are intrinsically difficult, but it's a lot to learn in addition to everything else a developer needs to know these days. The barrier to entry is consistently getting higher and specializing in one of the three disciplines is often discouraged.

-----

As a front-end coder, the delivery mechanisms aren't important to me. I have requirements that need to be met (geographic dispersal, session stickiness, etc.), but my job does not include setting up servers.

As a back-end coder, the container mechanisms aren't important to me. I need to know how to reach the database and 3rd-party APIs, and I have security requirements that need to be met, but my job does not include setting up servers.

As an operations engineer, the development languages aren't important to me. I know how to setup the right servers and containers and security and communication channels between everything, how to get the DNS to round-robin (or whatever solution for load-balancing I use), and I have security and performance requirements that I need to meet.

-----

Many of us are generalists in this sense. Developers very often know enough about web servers (Apache, nginx, etc.) and database servers (MySQL, PostgreSQL, Redis, MongoDB, etc.) to set them up reasonably well, and enough about TCP/IP to get everything running on a hosted server or two somewhere with working DNS. When VMs became popular as a way to ensure consistency between a bunch of different developer machines, we still didn't really need to worry about containers on the server. Then when containers became the next big thing, the tech wasn't quite ready for Joe Developer, but it was pretty well setup for Jane Devop.

And that's the crux of the problem - Kubernetes isn't necessarily hard for dev ops engineers since it's completely within their purview. It's asking developers to also be accomplished dev ops engineers that's creating difficulty. It's like requiring your mechanic to also be a professional race driver. It's like expecting your pilot to know how to rebuild a jet engine. Yes, there are some who can do it, but most of us are just barely making it work because we _have_ to and concentrating on the development instead.

If we want containers to be easy, then there should be a CLI that asks me a few questions (what host, what server-side language, what front-end requirements, what external services, etc.) and it spits out all the configuration I need to deploy to my host of choice with a single command. Better yet, build this into a build plugin for my IDE.

As a developer, I don't really want to know what all that stuff in an Apache or nginx config file does, but I need to. I shouldn't have to edit more than two or three lines in a PHP ini file to handle memory limits, but I need to. And I definitely shouldn't be deeply versed in two or three different deployment container technologies in order to get a job as a front-end developer.

PHP for sure - used it for years, wrote multiple frameworks for various things, then migrated to JavaScript and the front-end and now I can barely remember how to write PHP :(

I assume this is done the same way products like YNAB and even QuickBooks Online access your banking info - through an API provided by the bank (or it's website partner). Your act of logging in is enough to allow a partner (like Plaid) access to endpoints that contain your information, including transaction history, account info, etc. I don't think any of it is done through scraping - the chances of that information being wrong then become Plaid's problem, not the bank's, and there's no way in hell that would be acceptable to Plaid.

My advice is get out of the hosting business, it's not worth the trouble at a small scale ;)

There is always room for another hosting administration system, though 7 to 10 months sounds pretty optimistic when considering the feature list you'll need to even be seen as competitive with cPanel.

Webmin/Virtualmin seems like it has the ability to manage multiple VPSes, so that might be a more realistic target for comparison.

That's what Hostinger said when I contacted their support, but I literally did not have this problem with 100+ domains registered with other registrars (GoDaddy, Gandi, TUCOWS, Namecheap, Amazon, etc.) - it was just Hostinger. My suspicion is that they sell your information when you register a domain; I have no other explanation for the phenomenon.

I had a bad Hostinger experience. Within a couple hours of registering a pair of domain names through them in 2017, I started receiving spam emails and phone calls on that specific email address and phone line. Within a few weeks, I was getting upwards of 50 emails and a dozen or more calls every day. It took months to calm down, and even now 5 years later, I still get 10-15 emails and maybe 5 phone calls a month regarding one or the other of those two domains.

I have domains registered back to 2008 (and older ones I've let expire) and newer ones that are in their first year, and as far as I can tell *NONE* of them generate any kind of spam (or it's so infrequent that I literally miss it completely).

This only ever happened with Hostinger. And for the first couple of years, every email and phone call would explicitly reference one of the two domains I registered.

So I can recommend their hosting I guess, never had any problems with it, but I would never, ever register a domain with them again.

An article describing that technology and how came to be used would be a more appropriate link for HN.

Oh, and if you think that being called a pervert for sending a stranger dick picks is man-bashing, please turn in your Man Card and don't pretend to be anything other than a supporter of sending dick pics to strangers.

That you consider this article to be man bashing is telling.

I read it more as asshole/jerk/perv bashing. In the author's experience, those are primarily men, and in my own experience I would agree with that observation. Intent counts for a lot less than perception. It's narcissistic and toxic to expect everyone around you to understand your motivations without context; for example, the men she perceives as creepy who follow her professional _and_ personal social media accounts and spending time liking posts and pictures for longer than the first 10 minutes. At least some (or maybe most) of them are not being intentionally creepy. But it's a fair shot that a good number of them are (especially those who look up her personal accounts as well).

Our society spends a lot of time objectifying people, and if you think it's bashing when someone calls it out, you're probably part of the problem.

In teams I've worked on recently, it's been less of a "which is easier" and more of "what percentage of our customers would we reach".

Worldwide, Android phone significantly outnumber iPhones, but in Canada and the US, the split is pretty close to 50/50. At that point we would probably go with the platform the majority of the team is more comfortable with unless there was a specific business reason for going with a specific platform first.

Tucows, and nothing wrong with paying for Gmail either - a .com domain is maybe $15 per year (and other TLDs range from $1 to thousands)

Why did you post a pothole repair company website here?

Jurisage is sort of on the edge of this with their research software.

I've worked with a few different legal tech firms over the past few years and in my experience the exact opposite is true. Most lawyers (that I've seen) have embraced automation. Lawyers don't want to increase billable hours on bullshit, they want to bill more than 2 or 3 hours per day. If using some customized software or a properly setup Clio+Zapier lets them bill an extra hour or two a day, that's a win. Automation increases billable hours.

Doesn't using `npm ci` instead of `npm install` keep transitive dependencies pinned as well?

I don't really expect to find one (I won't have the results for an 8-character input until tomorrow afternoon sometime, and 9-character inputs around mid-March if I don't reboot my machine), but thought it would be an interesting experiment - and hey, blind luck can always play a part :) Plus I got to learn a little Rust!

At 1 million hashes per second (assuming that speed remains fairly constant - which it probably won't), it would take my machine around 2.5 trillion years to get through the entire 64^16 set! Once I get to source strings that are 20 characters long, I should have about a 25% chance of having found a collision

Netflix is fairly high quality, as far as it goes.

But Amazon Prime is stuffed to the gills with shitty movies (and they only display the IMDB rating for some of them, not sure what the algorithm for that is), and looking them up all the time takes too much time :(

I think you misspelled Android...

Yep, this is expected much of the time. Dev-Ops is basically always on-call.

I've stopped marketing myself as full-stack because I don't want to be on call. I can (and will) still do the job if needed, but prefer to specialize in my old age.

In my career (over 30 years now), full-stack in the context of web development has always referred to an engineer who could setup the tech stack and application from scratch. They can manage the servers, administer the network (as it relates to permissions for the various web-related processes), implement developer environments, code the back-end, code the front-end, some basic design skills, experience with developing UX, and is deeply familiar with the network protocols being used.

Anyone claiming to be full-stack should be able to handle light dev-ops for a small to medium sized company for at least a few days without breaking things. They should be able to sit in any other generalist coder's chair for a week. They should be able to work closely with a designer to help develop the look and feel of the application and have an understanding of the domain tools and language. They should be able to work closely with a DBA to help develop the best database for the application. They should be able to debug complex app behaviour with their understanding of how the different sections work, even if they don't have explicit knowledge of specific areas of the application.

A full-stack "developer" may only refer to the coding and design+UX portions of that description, but should still be very familiar with how the server software and network works. A single framework may provide a full-stack development solution (RoR, for example), but a full-stack engineer needs to cover a lot more ground than just development.