There are only two mistakes you can make:

1. you picked the "wrong" framework as in you should have picked the other framework.
2. you wasted time debating yourself what to pick longer than necessary.

the first one is not as problematic as the second. let me explain.

1. it is reversible. so once you realized you made a wrong choice, you can simply stopped and switched. yes, the time spent previously is lost but is not a complete loss because a lot of the concepts can be carried over as both follow the MVC structure. Django calls it MTV but is different names for the same thing. any experience building a website with one framework also can be reused when you switched to another framework because the experience is more to do with the nature of website building than the specific framework itself.

2. you need to debate with your self but beyond a certain point any additional debating is a waste and this is a complete waste. none of the time spending extra debate / research is transferable to any django or ror frameworks. none of the time spending extra debate / research is transferable to the general experience of building websites.

so once again pick the lesser of two evils. Do enough research set out a criteria, then apply that criteria and choose. Dive in deeply into one framework. Set a timebox on when to re-evaluate your choice. I recommend evaluating after building 3 mini sized websites or 6 months of part time building at abt 10 hrs a week at least, whichever is longer. If you can build full time (i.e. abt 30-40 hrs a week), then shorten to 3 mini-sized websites or 2 months of full time whichever is longer.

That should cover most edge cases i can think of.

Pick the one you’re more familiar with.

I was equally familiar with both abt 3-4 years ago when I started with a new client project when I had to pick a framework. Which meant at that time about zero.

Abt > 10 years before I used rails 2 in a stock market simulator project. Then I was project managing a django project and sometimes I had to go in and look at the code and help with small changes.

In the end I decided to pick django simply because I wanted to learn python.

Both are good enough

In fact I’m here in WIP because I’m my journey to learn django I “internet met” @jefftriplett who gave me invite here.

I faced this X and Y problem many years ago (>15 y ago). I was also told both are good enough. While intellectually I understood, I still persisted research.

Which was a waste of time.

Not saying you will also do that but if you do I understand and emphathize. Been there done that.

All I can say is this: either you pick a framework and move on to more impt stuff like understanding your user problem

Or

You spend more time researching like I once did.

I know the pain of using extra research as a way to procrastinate which is why about 3-4 years ago I decided to leave the php ecosystem when taking on a new client project, I needed to choose again. This time, I didn’t spend too much time with such research I did a cursory one between python and ruby and Javascript

Then between flask and django

Then that’s it.

Being intentional to be better in any framework or language matters more than the choice of language or framework

This is true for web technology afaik

Good luck 🤞

Start with an audience group you like or even better yet already a part of.

Why?

1. It's very unlikely you dislike an audience group you're part of.
2. It's very unlikely you cannot connect with an audience group you're part of.
3. It's very unlikely you cannot understand deeply the kind of specific pain points or pressing needs of your fellow tribe members from the same audience group you're part of.

Tho it's possible you belong to an audience group that cannot pay or cannot pay enough for your efforts. But if you find something pressing or important enough, someone will pay...

There are many ways things can go wrong.

Let's start with the build first approach.

1. You build a product but cannot get easy access to audience.
2. You build a product can get easy access to audience but they not interested.
3. You build a product can get easy access, they interested, but they cannot pay or cannot pay enough to make it worth your effort.

These 3 are for the build first approach.

Then the audience first approach (which i prefer) also can have many things wrong.

1. You find an audience but you cannot connect with them.
2. You find an audience you can connect with them, but you don't like them so you cannot stay connected with them for long.
3. You find an audience, you can connect with them, you like them but you cannot build the things that solve their pressing needs or pain points.
4. you find an audience you can connect with them, you like them, you can build but they cannot pay or pay enough to make it worth your effort.

The problems with build first tend to be the mirror image of audience first and vice versa.

Of all the problems i have, the least problem is building. Hence i choose the audience first approach. If i can find an audience and i like working with them and understanding them, and they can afford to pay, eventually i will be able to build something that works for them.

Case in point is my current revenue source a MNC client who can afford to pay, the main people i work with are nice and competent, tho i think some of the instructions from their upper management are a bit suboptimal and a small minority of the end users are not very good at their work which impacts me, and they asked me to build something i had no experience building and was complicated but eventually i figured it out .

Even tho it was not perfect and a bit 💩 but they kept using it cause it was so important for them.

Every time i build something before talking to any target audience or is a group i'm not already part of, it always fails.

Your mileage may vary.

thanks for providing both django and python specific

Not sure you meant by "managing creds", I'm looking at storing codebase specific env variables for production on github secrets at the repo level.

Then somehow use github actions to deploy and re-create the .env file for production environments

UPDATE:

I wrote up of my current approach as a SO answer to my own question.

Reproduced below:

I realized I should have fleshed out the whole target scenario more explicitly in terms of hard requirements.

Must use:

• Github Actions
• Ubuntu LTS VPS (I use DigitalOcean)

Must see:

• the codebase on the VPS be updated to latest main branch
• there is a new .env file in the project path on the VPS

I discover 2 general approaches.

Outline:
1. checkout action then rsync to update codebase
2. create-envfile then rsync

This approach uses mixture of GitHub Actions. Namely, checkout and create-envfile

1. ssh-action then
   1. git clone using bash script to update codebase
   2. create envfile using bash script

This approach uses 1 GitHub Action but it needs more bash scripting

I chose approach 2 because git clone is superior to rsync.

This is my ci.yml

name: Deploy via SSH
on: [workflow_dispatch]
jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    steps:
    - name: Deploy via SSH
      uses: appleboy/ssh-action@master
      with:
        host: ${{ secrets.SSH_HOST }}
        username: ${{ secrets.SSH_USERNAME }}
        key: ${{ secrets.SSH_KEY }}
        script: |
          # git update to latest codebase on main branch
          cd /path/to/project && git pull
          # updating the .env file
          cat <<EOF > ${{ secrets.ENVFILE_PATH }}
          # start of envfile
          DJANGO_SECRET_KEY=${{ secrets.ENVFILE_DJANGO_SECRET_KEY }}
          # end of envfile
          EOF
          # see end result of envfile
          ls -l ${{ secrets.ENVFILE_PATH }}

As for how to save the secrets to your GitHub repo for SSH access, please check this article

Note: the cloudflare was overzealous in hiding the repo and branch name which uses the @ symbol. So best to go read the SO answer to see the full response

Is the direnv used for development envrionments on laptop? or also for production environments on linux VPS servers?

Will do

Scheduled 1 more interview

Waitlist is now 15 as of 2021-05-29 19:39

Yes I did I spoke with 5 people as of today. Tho 1 of them I stumble on via Twitter so he’s not added on to the wait list. Strangely he spoke with me the longest. Nearly 3 hrs

Waitlist is now 8 people long