I’d be willing to learn something new if I knew in 2 years, I’d be extremely productive.
I’d be willing to learn something new if I knew in 2 years, I’d be extremely productive.
1) Install docker and docker-compose
2) Setup traefik, a reverse proxy, in docker (good starting point: https://docs.traefik.io/user-guide/docker-and-lets-encrypt/ ).
3) Run $docker container (ghost, wordpress...). I typically use one docker-compose file for each domain. "expose" is not necessary because the requests are proxied by traefik.
Here's a docker-compose sample for a website available under my-website.com:
version: '3'
services:
web:
container_name: my-website.com-nginx
image: nginx
restart: unless-stopped
volumes:
- ./data:/usr/share/nginx/html
labels:
- "traefik.docker.network=web"
- "traefik.enable=true"
- "traefik.basic.frontend.rule=Host:my-website.com"
- "traefik.basic.port=80"
- "traefik.basic.protocol=http"
networks:
default:
external:
name: web
There are probably more elegant ways to do this, however I found it quite effective for my setup.You get a bsd host with shell access for cheap.
Eventually moved on when my needs evolved and sort of...forgot about them until this comment.
But moving my static sites to S3 would be considerably cheaper.
Put Docker on your VM / instance, make a project with a docker-compose that just ties one or many services together with traefik as the reverse proxy (I use CNAMEs or subdomain routing - path routing & stripping adds complexity and breaks many apps).
For the actual site you can choose any stack you desire. I'd recommend node / express over wordpress for a simple site, but you can rock a flavor of the month, or whatever your experience allows you to be productive in - Swift Vapor, go, php, .NET... then dockerize your site.
Deploys and execution should be identical locally and remotely. If you get popular, you are in a great place to scale out compared to many traditional stacks. If you want to try out another service, tool, database, whatever; just add it to the docker-compose, run docker-compose down/up, and there she is.
There is a sharp initial learning curve with Docker - images, containers and their layers, volumes, networks and ports, and how all that interacts with the host machine. Containerization is arguable something you won't be able to ignore forever. The advantages are just too numerous and appealing, especially for the hero solo developer!
Then just get shared web hosting account - there are lots to chose from and they are super cheap these days. You can go a long way with that without having to mess around with maintaining your own server (unless you want to - I do :)
I left open my prior tools, etc so as not to bias the answers. I’ve done lots of Java, Python, Swift, some Go, etc but I’m willing to learn anything, so forget that you know that.
I’m looking for a big lever.
But since you say you are comfortable with programming, then a static site generator might be interesting for you. Pick one in whatever language you prefer. Be prepared to spend a lot of time before you are as productive as writing it by hand.
I have Atom, VSCode, Sublime, JetBrains, ... I know vi and Emacs. I’ve programmed websites in Perl, Python, Java, Go, ... I didn’t realize we differentiate between applications and sites these days.
In 2019, I’m one person who is willing to start with a clean slate. What current tools should I choose so, as one person, I’m most productive 6 months from now, once I’ve mastered the new tools.
The idea is to choose an above average stack:
“Software is a very competitive business, prone to natural monopolies. A company that gets software written faster and better will, all other things being equal, put its competitors out of business. And when you're starting a startup, you feel this very keenly.”
I’m not exactly sure why what I’m asking is not clear.
One person with great tools can accomplish a lot more than a small team with average tools. Wasn’t that the reason Ruby was a much better choice than Java/JSP a decade ago? I was never allowed to chose Ruby, for example, because my company required Java.
Today, there are even more options and it’s not clear where to begin the evaluation.
It really depends upon what you want to do. My own website [1] is written in XML and I use XSLT to convert it to HTML [2]. My blog [3] uses a mixture of C and Lua [4] because that's what works for me. A great craftsman can make wonderful items with average tools that an average craftsman with great tools cannot. It's not just the tools, but how well you understand them and what their limitations are [5]. Also, the industry changes. Hell, javascript didn't even exist when I started making websites. Nor did Java. I got taught CS 101 in Fortran of all languages. The only constant is change, so stop asking what's best, and just start working. You'll find out what works for you and what doesn't.
[2] I wanted an easier way to maintain the links among all the pages (next section, previous section, next page, previous page, etc.) instead of modifying static files. XSLT was the new hotness at the time. I won't say it was a mistake, but I haven't bothered changing the underlying technology since.
[4] https://github.com/spc476/mod_blog
[5] I know of a bridge player (a card game) who took the time to learn x86 assembly language to write his own bridge playing software, and from my understanding, at the time it was a "best of breed" type program. Could he have been more productive in another language? Perhaps. Perhaps not.
It's not really a sensible question IMO. It's like what's the best car - I say 1980s Countach ... then you say, but I can't fit my luggage in, so I say a Landrover Disco', and you say it doesn't fit in my garage, so I say a Porsche Cayenne and you say it's too expensive, ...
The best stack depends entirely on what you want to do with it, and yes web apps and web sites need different things (I'd say the former are computational, the latter are presentational).
Background: I've been doing solo web dev (but never full-time professionally and mostly casually) since last millennium.
The language and the compiler is in the browser. The source code is HTML/CSS. Use VSCode, Atom, Sublime or even Dreamweaver to write that code.
I differentiate far more than that. Just as you wouldn't make the same tool choices for a throwaway, ten line script, a command line tool with five subcommands, and a full word processor, you can't expect to do the same for a website.
If what you need to do is put fixed web pages online, then a text editor and an SFTP client is exactly it. Write your HTML and CSS by hand and get on with life. It still works beautifully.
Just past that point is the uncomfortable place where you want to do some templating. And this is where it seems so simple just to hack together a quick script to do what you want that there are a million static site generators, and it's questionable if it's easier to write your own or learn how someone else has organized one. This is a place where no one has gotten it obviously right yet. I still use Hakyll because I got it working a while back and haven't been motivated to change. I've looked at Hugo and Jekyll. I've experimented a bit with writing my own. It's just not worth the effort.
At this point in time, the two things I think would be worth investigating in this space would be either precompiling web components to static HTML so you can use an existing standard that scales to web apps or going into something like Smalltalk and defining objects with content and metadata as objects in a live system then having the code generate output directly.
Do you want to fuck around with building another CMS that nobody but you will use, and which you will probably only use for about three posts before throwing it out and making another CMS built on today’s hot tools? Or do you want a website that you can get to be reasonably pretty without much work, and which you can update from multiple devices?
Seriously I spent a while setting up WP a decade ago and it’s been where I post everything I make. I don’t have to futz with it unless I want to make a cool new theme for a new comics project, it just sits there updating itself for me and waiting for me to feel like writing a new post or whatever.
(Okay I do need to spend some time futzing with it soon, the latest WP update won’t run on the decade-old version of PHP I set it up with, and something in it breaks when I try to switch which version my shared host is using. That’s once in like a decade.)
I very much agree in the sense of start simple, and grow. My progression was plain html, html plus php for header and footer, text file based CMS, finally a db-backed CMS that does everything I want how I want it. But that was also starting with knowing next to nothing, and to do it differently (more "efficiently") from the get go, I would have needed to just accept advice to use X, without really understanding what it does for me. I was a bit stubborn and not just suffering from NIH syndrome, I was in the cult of NIH. But I learned, it was fun, and I am glad how it worked out.
As the saying goes, "If you wish to make an apple pie from scratch, you must first invent the universe."
I like that I'm able to design everything from the ground-up the way I want it. Also a decent selection of themes if you wanted to focus on content.
Statik: https://pypi.org/project/statik/
There are lots of templates free, or for purchase you can use, cut up and deploy. It really all depends.
Many just dip into wordpress, which for good or bad is pretty much the king of CMS. Others Drupal or similar.
Not static, but easy to backup (plain text instead of database), many plugins, article versioning, easy editing (even on the mobile phone), a servicable, if unexciting, design that's mobile friendly.
If you want to be productive, and "productive" does not mean building web software (which is fine!), worry less about the software and write more.
Many people recommend Jekyll/Hugo/Vue-press + Netlify as well.
Curious: why not? Before WordPress and MoveableType websites were largely static HTML, where do you personally draw the distinction?
For simple sites, static is great, but if it becomes more complex (even just lots of pages sort of complex) then some sort of templating, even just through basic PHP includes, becomes very helpful to keep it maintainable. Example: I help look after a site with 3K static HTML pages and it is impossible to make any global changes without literally months of manual work. :(
For my own site I use a static site generator, which is another great option, but that comes with a much steeper learning curve unfortunately.
Simply because it is very limiting.
Seems like a limited/narrow definition of maintaining a website, just because there are different options of platforms and tools used to put content in the user's browser. Ultimately, for the browser, the result is the same, no?
Edit:
Following your edit, I can see an argument being made that maintaining static sites coming with a different workflow than maintaining a CMS and why some may not prefer it --personally, the mutability of the workflow for many of these stacks is the appeal of SSGs for me (especially, more recently 11ty[1] which I'm thinking of porting my personal site to).
It is my job to know a LOT about putting content in users browsers (from TCP protocol level up to the HTML) but I still think that GitHub pages is too limited for anything but very simple site.
It’s cool to have a static site - it’s not cool to be forced to only have a static site.
Oh we wont disagree there, it absolutely has its limitations.
You had originally stated you don't consider these types of stacks to be "running my own site" and I was just wondering what the distinction was, not to necessarily call into question or invalidate your own experiences-if I gave that impression, it's on me to communicate myself a bit better next time.