kayman

If you're an emacs user and you code in emacs, magit works really well with your workflow.

I feel like development has come full circle. Initially, it was all server side.

Then we had to use javascript to do some frontend stuff.

The javascript became frameworks which templated some of the patterns to make the frontend dev easier (led by React and Angular)

Frameworks like Blazor and Phoenix/Elixir are bringing the frontend dev back to serverside.

I used to do limit orders - try to save some money by buying a stock when it's at lowest during the day.

Then I read a book by Fischer called "Common Stocks, Uncommon Profits"which suggested that when you have a long investment horizon, say 5-10 years, and you have done the research to have the confidence, a limit order gives you no real benefit.

Say a stock is $100 today. In 5-7 years you expect it to be $500, the benefits of doing a limit order are less significant.

For bootstrapped projects without a PMF - which are my side projects I self host.

Postgres hot hot with 2 servers.

For clients I always recommend PaaS

Try the steelcase leap v2.

Aeron Miller was the 2nd alternative but ended up going with steelcase.

I've had it for almost a year and would still recommend it.

Similar to "bourne shell" and "bourne again shell" aka bash

I can see the evolution now. "nushell". Next iteration: "nuer shell" (newer) or "renushell" (renew)

It’s because the average person has so many passwords in various formats that they forget. But that person most likely has access to their email. Instead of taking the user on a password reset journey, just shortcut to login. The attack vector is restricted to email no matter what.

The reason your username and password are on different pages is to handle federated identities. Take a typical saas product. Initially you build your own login username and password. As you grow your users ask to login using gmail, LinkedIn or Microsoft so they don’t have to remember multiple usernames and passwords. If you enable third party login it means you have to redirect the site to the third party login page to authenticate.

To accomodate that you design your page so the user first enters username. In your system you check based on email who the identity provider is and redirect to that login journey.

For e.g. if Microsoft you redirect to Microsoft login page to authenticate.

If successful the third party login provider will send you back to your app with a JWT. In your app you check if the JWT is valid - if so allow access.

On first entering email on login, If your login provider is your own app, you redirect to your own login password page.

In my experience, when people build apps without having to write code, the first iteration is awesome. Get something working and shows great promise. But as complexity grows, the app ends up being a badly designed excel screen on the web.

I've been off Facebook for many years now. I deleted my account when I found myself typing "f" into my browser. Facebook dropdown, select and lose time scrolling feeds.

I never got into instagram. As an american expat I find whatsapp convenient to contact my family overseas using their day-to-day telephone.

As someone who has been on both sides of the coin. My take is: Don't make your site for anyone and everyone. Keep a target audience in mind. Most of the time, the person that hires you is usually the target audience.

Don't try to be too cute. For example, I have seen sites/resumes where the whole thing looks like HTML tags. My first impression is "cute" but it makes it hard to read as you try to gather real information.

Most of the time when someone is looking at your site, they are asking themselves: - Who is is this person?

- What do they do?

- How much will it cost me. (Does it look expensive, cheap or reasonable what tier do they fall into. ex: Dominos pizza or Gourmet Pizza)

- Have they done any projects that are similar to what I'm looking to get done.

- Are they competent

- Do they look like someone I enjoy working with. (energy, attitude, views...)

+1 for keeweb. It's central to my password management strategy now. Can't recommend it enough.

I've tried the offline versions, but I find myself often on the go - without my laptop.

The tools for mobile don't seem to support updates - read only. Keeweb does both.

> That's a slippery slope argument. Do you want to nationalize nothing?

I meant where do we draw the line?