Python for the code, Postgres for the backend, Markdown for the frontend. Because I am too lazy to reinvent the wheel, and most of that is good enough.
I would have much preferred to use Perl, R, dotnet, or just about anything else, but there was an already made library in Python that was good enough for 90% of my needs, and 100% with some elbow grease, so my lazyness made me learn Python instead!
But wait- it gets dirtier than this! The code is done is Vi, with no care in the world about version control (rsync does most of what I need: backups), and deployed to servers by manual SCP, with no automatic tests, no care about CD or automatization - yet: as I need more and more servers, I realize I have to spend time learning say ansible to provision them faster than a copy paste of bash (I have low standards but I won't do curl|bash, just... no) but I am delaying that as much as possible to concentate on implementation.
The servers are on Debian VMs on Azure, just because they gave me free credits and do not perform as bad as AWS. When the free credits run out, I will move to DO. Then I will see what else I can use, and that will be the right time to care about ansible or whatever.
It is as ugly as I can get away with to get my MVP out, using tech from 1996 lol.
People saying they wouldn't use git don't know git. I admit it does take investment to learn but once you are over the hump it is insanely easy and useful (yes even easier than rsync and 10x more useful). Especially when you consider that using rsync precludes your from collaborating even with one other person which is crazy easy if you use github (for example). People not using git: get over the hump, it is worth it, even on little side projects.
I agree with you 95%. If you're running something basic with less than 5 people this is reasonable with one minor caveat:
I'd still use git.
Hell even on my own I frequently use git for single file shell script. Commit a working copy. Tweak it to add a feature. Decide it's unmaintainable. Revert to before I fucked it up.
Also, theres a decent half-step between ssh and Ansible: mssh. You can run ssh across a set of hosts quite trivially. It working on the order of a few dozen machines just fine.
Pretty much the same except that I use `git push` to deploy instead of `scp`. If I ever need to move beyond a single server that'll be an issue but for now it's fine.
For my hobby stuff I am similar. Perl and either SQLite or Text files. Sometimes Postgres, but I rarely find it is needed, even for fairly popular anonymous boards.
I use vi. I do use git locally, but I don't trust it, so I also use rsnapshot, probably similar to your rsync. You might want to try rsnapshot some time if you have not. It uses less disk space by hard linking dupes using a perl script.
I'm writing it in Elixir and Phoenix (Elixir's goto web framework) with PostgreSQL to back my data. For the front end, I'm using good old fashioned server side rendered templates and Turbolinks with sprinkles of Javascript where needed.
Despite having worked with Flask and Rails for the last 6-7 years I'm going for Elixir this time around because there are aspects of the app that lend itself well to what Phoenix has to offer and I'm using this as an opportunity to grow as a developer. Every time I learn a new language / framework I find myself leveling up in other technologies I know.
So far I'm super excited with the way things are turning out. I'm still pretty early on in the project but I've gotten a decent amount of functionality implemented already.
I'm really surprised Elixir isn't more popular. The language author and the supporting community is awesome, and I've been the happiest I've ever been working with this tech stack. Of course I'm still drinking the "omg this is new and awesome" kool-aid, but even without really knowing everything too well, I'm able to accomplish real world tasks and that's all I care about in the end.
In Elixir+Phoenix you get all the CRUD conveniences as in other frameworks, but you also get trivial Reactive/real-time capabilities that would get very hairy in something like Rails.
Go and, honestly, sqlite with backups written to S3. It's the absolute cheapest. I can run multiple apps on a t2.nano (t2.micro if I am feeling fancy). My apps cost something like $1.50 to run a month, and they can easily handle medium-sized traffic, plus Go is just so dead simple to deploy. scp a build binary, and boom I am done. Once the app grows and more collaboration/developers/requirements call for it, I will add more infrastructure.
Thanks for sharing your setup here. Go and SQLite are great! I have a few questions :-)
Is the Go service directly accessible from Internet, or is it hosted behind a reverse proxy?
When you deploy a new binary, is there a small downtime between stopping the old binary and starting the new one?
How do you supervise the Go process? You use something like systemd?
When SQLite backup is ongoing, does it block writes to the database?
When you backup to S3, if an attacker gets control of your EC2 instance, is he able to erase your S3 backups, or is it configured in some kind of append-only mode?
Where do you store your logs and do you "read" them?
Not that I'm counting, but there are 20 mentions of React, 13 mentions of Vue, 10 mentions of Python, 9 mentions of Go, 8 mentions of rails. The OP had a couple mentions of Wordpress.
AND Zero mentions of Meteor, lol!
I think I'm the only indie developer using Meteor and Blaze, but I have to say they make my life WAY better. Granted, it took some time to figure out exactly how to optimize the stack to make it scale correctly, but NOW Meteor is the only solution I've heard of that does this:
Meteor now automatically builds two sets of client-side assets, one tailored to the capabilities of modern browsers, and the other designed to work equally well in all supported browsers, so that legacy browsers can continue working exactly as they did before. This “legacy” bundle is equivalent to what Meteor 1.5 and 1.6 delivered to every browser, so the crucial difference in Meteor 1.7 is simply that modern browsers will begin receiving code that is much closer to what you originally wrote.
The apps I build now run like native apps in a modern browser. Laser fast. It's beautiful, like the first time using broadband.
After everyone and their mother proclaimed Meteor to be dead, they rose from the grave and locked in like Godzilla. I don't begrudge anyone their choices, but if you haven't taken a look at Meteor lately, having used Wordpress, Rails, Ember, React, and vanilla JS with node in the past, I'm very grateful Meteor's development team is STILL knocking it out of the park.
I can assure you that you are not alone. I am developing meteor with react. I took the clever beagle pup as the base. My app is a working smoothly and meteor does a lot of things which I don't completely understand, but it just works.:)
It’s not cool anymore but I use PHP and MySQL with a $5/mo inmotionhosting account. This is after I decided to not take on the overhead of native with multiple code base and App Store deployments. Good ol’ webapp it is.
However every single day I do wish there was a solution for my webapp to get access to contacts on the phone and of course notifications. It would have been a game changer given the nature of the product. Currently it is a world of compromises for hobby developers (shameless plug: http://ping3.com)
I use the lamp stack too, hosting on scaleway nowadays; aws is great but for my own non critical hobbiest projects scaleway is hard to beat. Having said that, cpanel is great on shared hosting with the ability to specify your PHP version and modules.
As a language PHP can be a mess but the ecosystem is fantastic; the release of PSRs, composer and 7.x have been great.
For getting web apps up fast, React, Firebase, Git, and Heroku. It's a well trodden path so the tooling is simple and the components are reliable.
For my VR stuff... Unity is really the only choice that's fast to get off the ground, so Unity it is.
For hacking together backend heavy stuff, Python. Flask if I need to expose an API endpoint. Postgres if I need a real database, sqlite if I don't. Deployed to my evergreen playpen virtual instance via Docker containers because it's, once again, a well trodden, simple, and undramatic path.
Do you use firebase auth? It looks really good. I just had a heck of a time implementing user management and a couple oauth2 flows and it looks like it could have saved me a bit of time. My only concern is their plans are a little weird, it just jumps from free tier to jumbo size, wish there was something a little in between for less money.
I'm curious, I've started doing development in unity but I find myself unaware of good patterns to use, any pointers to advice on unity design patterns?
I built FormAPI [1] with Ruby on Rails. I used plain Rails views for most of the CRUD things, and used React/Redux to build the template editor [2], which is pretty complex. I've been extremely productive with Rails, and the performance has not been an issue at all. My plan is to rewrite the API and workers in Elixir when it will save me $2,000 per month on hosting costs. And even then, I would probably be making so much money that it wouldn't matter.
I started on Heroku, but I had a lot of free AWS credits from Stripe Atlas that I wanted to use. So I moved to Convox [3] on AWS, and it has been absolutely awesome. I have a rock-solid cluster across 3 different availability zones, and I'm also running Postgres with high availability (RDS).
I haven't had a single second of downtime since I migrated [4] (I up the status dashboard a few months ago, but moved to AWS earlier than that.) Convox supports auto-scaling and rolling deploys. It waits for the web process to be healthy, and if something crashes it rolls back the deploy without any downtime. I can also terminate any instance at will, and another one will pop up to replace it with zero downtime. After using it for the last ~6 months, I feel confident enough to start offering a 99.999% SLA.
Flask (hosted by pythonanywhere) and Neo4j from Graphene.
Chose both because I wanted consistency between the abstraction of my business logic, and the spec of my implementation.
I get some chippy guff about using graphs, but by taking the time to define my business logic as a grammar, expressing that grammar as a graph, then implementing it directly into the model, I get a lot of "aha," moments from potential customers.
Graphs can be analogous to functional languages in that if you are using them, there is a higher likelyhood you've reasoned something through before implementing it.
I actually wound up building most of my current project in Rust, on top of actix-web.
Partly because I'm apparently a masochist, but also because... I mean c'mon, modern architecture is CRUD and job queues. Rust can do that fine if you don't get distracted by the bells and whistles.
My stack: Gitlab CI/CD, deploying using Ansible to Docker Swarm, running Keycloak for auth, RabbitMQ for messaging, Postgres, Elixir/Phoenix for the API server (GraphQL), Apollo + React Native for frontend and mobile apps.
Why? For me it's best of breed vs simplicity. OpenID Connect is the most mature auth, rabbitmq very good messaging, elixir a lovely language, graphql the most programmer-friendly connection between frontend and backend, and react native allows 90% code sharing between web SPA and mobile apps.
And if you combine all of these (I mean if you finally set it all up), it's a low number of lines of code environment.
Speaking for myself: mainly Groovy and Grails, with a little Java mixed in. Postgresql when I need a relational DB. Bootstrap for basic CSS, and jQuery to add AJAXy bits. I have not yet adopted a JS framework like React or Vue, although I've been looking at giving Vue a shot. I use Ansible for automation, Git for version control, Eclipse as an IDE. Deploy to CentOS linux mostly. Just starting to go down the path of adopting Docker and (probably) Kubernetes. Cloud infrastructure is either Linode or AWS.
All of that said, I'm a big believer in "use the right tool for the job" so if something comes up that requires C++, I'll use C++. If something needs Python, then Python it will be. If Prolog is right for something, I'll use Prolog. Or COBOL, or Erlang, or Ruby, or CL, or Perl, or SNOBOL, etc., etc, yadda, yadda, ad infinitum...
My side project is using Rails, React, Postgres, and deployed to heroku. There’s nothing flashy but I can prototype quickly and it’s easy for 2 people to manage.
My software dev path:
Didn't know anything serious about web dev/software systems 12 months ago.
So if my stack seems shiny, I just picked what many people on Medium/Hacker News were talking/raving about.
Front-end: React SPA (Via Create React App),Redux, React-Bootstrap
Why: I had no prior framework experience, single command setup, and plenty questions on Stack Overflow and Medium articles to learn with.
Going the plain Javascript route with no frame work,seemed like I would be on a slippery slope for spaghetti code down the line.
React's one-way data flow and component architecture made things incredibly easy to mentally digest.
I found React's documentation VERY well organized and explained, and Vue's documentation was intimidating when compared to React.
Version Control: BitBucket Git
Why: Free private tier for solo use and enjoyed previous experience with Atlassian products
CI/CD: BitBucket Pipelines
Why: Already using Bitbucket, this just worked seamlessly with it. Only $10 for 1000 more build minutes.
Firebase: Hosting/Cloud Functions/Firestore/Auth
Why: Everything is automagical
HTTPS static website hosting for the create-react-app (This is what first got me started)
Then came Storage,Firestore,Cloud Functions, and Auth.
Wish it had an automagical SQL product.
Low Entry Cost
Cloud Provider: Google Cloud
Why: Had no experience with any cloud provider.
I found the pricing/product offerings really easy to digest and interpret when compared to AWS.
Email Sender: Sendgrid
Why: Good starting free tier. Decent Docs. Easy to setup.
Backend Compute: Google Compute Engine +Docker+Python-based API app
Why: I can do local dev easily with Docker, push the image to Google Container Registry, then pull the image to the VM.
It's easier to do than learning to setup a CI/CD piped GKE cluster
Eventually I want to pay the "tax" go to a GKE CI/CD Kelsy Hightower setup,so I can git push/PR/merge a change, and it's in production.
I don't do enough changes to the backend right now to justify a CI/CD piped GKE setup.
Other:
Email Client: Gsuite
Why: Custom Domain Name
I'm already familiar with Gmail
Project Management: Trello
Why: Integrates with Bitbucket
Multi Device Support (Phone,Tablet,Desktop)
Easy to mind map and organize features
What I value:
Good Docs
Free tier for solo devs/low use, and progressive options for paid plans (Gives me breathing room on cash while I figure things out)
Lots of questions/answers on Stack Overflow or in-depth Medium articles.
Currently been working on a web app for about 8 months.
Python for the backend under the argument of "build using what you know". ReactJS for frontend development because Python for frontend work I find very antiquated.
Architecture wise I'm hosted in AWS. Data is stored in MySQL and Redis. All self hosted because I'm to cheap to pay per request pricing and the overhead is very minor when done right when rolling my own
I use multiplatform Kotlin to compile shared business logic to JVM and Javascript. The frontend then uses Typescript+React/Redux while the backend is a Kotlin Spring app with Postgres.
For the backend I start with Node, then get tired of the runtime errors and switch to Go. Go is cool but soon I get tired of writing “if err == nil” so I switch to Haskell. Haskell is nice but soon I get tired of not finding decent libraries for some not very popular things that I use, so I say fuck it and go to rails. Ruby is nice and Rails feels well thought out and solid, but then I can’t help be annoyed that it’s not fast, so fuck it, I switch to Rust. I get tired of lifetimes and wrapping everything in RefCells so I switch to Erlang. Erlang is cool and all, but no fucking meta programming. Sucks, let’s try Lisp...
I am not making fast progress, I think the problem is my keyboard, I should try buying that Ducky one I have been eyeing for quite a while.
Before you write a line of code, make a clear decision as to whether it's a learning experience or a business venture. Plan your project based on the goal you've chosen. If it's a learning experience, consciously avoid doing anything that doesn't push you to learn something new. If it's a business venture, consciously avoid doing anything unless you believe it has the highest RoI.
Some purely recreational projects do turn into viable businesses, but far more projects have failed due to indecision and yak shaving. If you're building a business, you don't gain anything by experimenting with a new stack. If you're learning React, you don't gain anything by writing a bunch of CSS and marketing copy. Don't be afraid to step away from the keyboard and ask yourself "Is this a good use of my time?".
I had to make this decision recently and my conclusion was if your goal is to build something that makes money, do it with what you know. Why? Because you can spend 100% of your time building instead of 50/50 learning/building (or worse). Projects with the goal of being a business should iterate and fail fast. If you win the app lottery and actually build something people will pay for, they won't want to wait for you to learn while you build it out. Someone else will do it with some "old" tech like ruby on rails and take your customers and revenue. Spend your time working on the business, not the tech. Developers think code is important but the reality is that it almost doesn't matter. You can build something successful with the worst tech decisions imaginable. I know it's hard to accept but it's true. I've personally witnessed an absolute frankenstein's monster app, made of a mish-mash of what are now considered the worst technologies, get sold for $30+ million and the founders retired to the Caribbean where the build a mansion and an upscale restaurant just for fun. I pity the people devs who have to inherit that, but the value wasn't in the tech and it almost never is.
I've also heard for side projects when you want to learn a new technology to experiment with one piece of it, so you're not totally overwhelmed, and so you can see how it works with stuff you know. For instance, use the rails backend deployed to AWS that you know, but swap out angular for react. I think this works for your question pretty well - if the side project becomes a money-making project, at least there's only one part of it that will be a technical risk, and often if you need to do something quickly, you can work around and do it in the parts that you know.
Prioritize. If your goal is to get something out quickly and make money, use what you know. If your goal is to learn a new stack, learn the new stack. If you learn enough to comfortably release to customers, do it; otherwise, either get comfortable or rebuild.
The intention at the outset. There's a low chance of success whether you are trying to make money or not. If you make money accidentally in a new tech stack... who cares because you can afford to support it.
Also build using what you know isn't always the best advice. Figure out what you want to optimize for and optimize for it. That may include doing things in a different stack.
C++/Qt for GUI, Go or Python for backend, Python for misc scripts/prototypes, C for uCs. They are all well trodden paths with plenty of good libraries available, and good tooling available. I have spent a bit of time playing with Zig most recently, it could finally replace C for me!
React/Redux frontend and .Net Core for backend API. The site takes advantage of Server-Side Rendering and Lazy Loading based on Routes/components. Authentication is built into the App with JWT and Authorize attributes on controllers.
[+] [-] 1996|7 years ago|reply
I would have much preferred to use Perl, R, dotnet, or just about anything else, but there was an already made library in Python that was good enough for 90% of my needs, and 100% with some elbow grease, so my lazyness made me learn Python instead!
But wait- it gets dirtier than this! The code is done is Vi, with no care in the world about version control (rsync does most of what I need: backups), and deployed to servers by manual SCP, with no automatic tests, no care about CD or automatization - yet: as I need more and more servers, I realize I have to spend time learning say ansible to provision them faster than a copy paste of bash (I have low standards but I won't do curl|bash, just... no) but I am delaying that as much as possible to concentate on implementation.
The servers are on Debian VMs on Azure, just because they gave me free credits and do not perform as bad as AWS. When the free credits run out, I will move to DO. Then I will see what else I can use, and that will be the right time to care about ansible or whatever.
It is as ugly as I can get away with to get my MVP out, using tech from 1996 lol.
[+] [-] eagsalazar2|7 years ago|reply
[+] [-] kjeetgill|7 years ago|reply
Also, theres a decent half-step between ssh and Ansible: mssh. You can run ssh across a set of hosts quite trivially. It working on the order of a few dozen machines just fine.
[+] [-] paulddraper|7 years ago|reply
I get the simplicity...but using git/hg/svn is just so easy. And you can easily rewind, diff, view changelogs for a file, etc.
[+] [-] brett40324|7 years ago|reply
[+] [-] ecdavis|7 years ago|reply
[+] [-] LinuxBender|7 years ago|reply
I use vi. I do use git locally, but I don't trust it, so I also use rsnapshot, probably similar to your rsync. You might want to try rsnapshot some time if you have not. It uses less disk space by hard linking dupes using a perl script.
[+] [-] ekovarski|7 years ago|reply
[+] [-] openIce|7 years ago|reply
[deleted]
[+] [-] nickjj|7 years ago|reply
I'm writing it in Elixir and Phoenix (Elixir's goto web framework) with PostgreSQL to back my data. For the front end, I'm using good old fashioned server side rendered templates and Turbolinks with sprinkles of Javascript where needed.
Despite having worked with Flask and Rails for the last 6-7 years I'm going for Elixir this time around because there are aspects of the app that lend itself well to what Phoenix has to offer and I'm using this as an opportunity to grow as a developer. Every time I learn a new language / framework I find myself leveling up in other technologies I know.
So far I'm super excited with the way things are turning out. I'm still pretty early on in the project but I've gotten a decent amount of functionality implemented already.
I'm really surprised Elixir isn't more popular. The language author and the supporting community is awesome, and I've been the happiest I've ever been working with this tech stack. Of course I'm still drinking the "omg this is new and awesome" kool-aid, but even without really knowing everything too well, I'm able to accomplish real world tasks and that's all I care about in the end.
[+] [-] brandonmenc|7 years ago|reply
Sprinkling in either Elm or Vue for the one or two complicated widgets I'm going to need, but I haven't committed to either one yet.
[+] [-] thedoops|7 years ago|reply
[+] [-] jimmy1|7 years ago|reply
[+] [-] xor1|7 years ago|reply
[+] [-] ngrilly|7 years ago|reply
Is the Go service directly accessible from Internet, or is it hosted behind a reverse proxy?
When you deploy a new binary, is there a small downtime between stopping the old binary and starting the new one?
How do you supervise the Go process? You use something like systemd?
When SQLite backup is ongoing, does it block writes to the database?
When you backup to S3, if an attacker gets control of your EC2 instance, is he able to erase your S3 backups, or is it configured in some kind of append-only mode?
Where do you store your logs and do you "read" them?
[+] [-] ArtWomb|7 years ago|reply
https://blog.sgmansfield.com/2016/06/how-to-block-forever-in...
[+] [-] startupdiscuss|7 years ago|reply
[+] [-] copperx|7 years ago|reply
[+] [-] robotkdick|7 years ago|reply
AND Zero mentions of Meteor, lol!
I think I'm the only indie developer using Meteor and Blaze, but I have to say they make my life WAY better. Granted, it took some time to figure out exactly how to optimize the stack to make it scale correctly, but NOW Meteor is the only solution I've heard of that does this:
Meteor now automatically builds two sets of client-side assets, one tailored to the capabilities of modern browsers, and the other designed to work equally well in all supported browsers, so that legacy browsers can continue working exactly as they did before. This “legacy” bundle is equivalent to what Meteor 1.5 and 1.6 delivered to every browser, so the crucial difference in Meteor 1.7 is simply that modern browsers will begin receiving code that is much closer to what you originally wrote.
The apps I build now run like native apps in a modern browser. Laser fast. It's beautiful, like the first time using broadband.
After everyone and their mother proclaimed Meteor to be dead, they rose from the grave and locked in like Godzilla. I don't begrudge anyone their choices, but if you haven't taken a look at Meteor lately, having used Wordpress, Rails, Ember, React, and vanilla JS with node in the past, I'm very grateful Meteor's development team is STILL knocking it out of the park.
[+] [-] ai_ia|7 years ago|reply
[+] [-] zhdc1|7 years ago|reply
[+] [-] terenceng2010|7 years ago|reply
[+] [-] riantogo|7 years ago|reply
However every single day I do wish there was a solution for my webapp to get access to contacts on the phone and of course notifications. It would have been a game changer given the nature of the product. Currently it is a world of compromises for hobby developers (shameless plug: http://ping3.com)
[+] [-] andrewmackrodt|7 years ago|reply
As a language PHP can be a mess but the ecosystem is fantastic; the release of PSRs, composer and 7.x have been great.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] i_made_a_booboo|7 years ago|reply
[+] [-] munchbunny|7 years ago|reply
For my VR stuff... Unity is really the only choice that's fast to get off the ground, so Unity it is.
For hacking together backend heavy stuff, Python. Flask if I need to expose an API endpoint. Postgres if I need a real database, sqlite if I don't. Deployed to my evergreen playpen virtual instance via Docker containers because it's, once again, a well trodden, simple, and undramatic path.
[+] [-] jimmy1|7 years ago|reply
[+] [-] sampl|7 years ago|reply
[+] [-] foota|7 years ago|reply
[+] [-] nathan_f77|7 years ago|reply
I started on Heroku, but I had a lot of free AWS credits from Stripe Atlas that I wanted to use. So I moved to Convox [3] on AWS, and it has been absolutely awesome. I have a rock-solid cluster across 3 different availability zones, and I'm also running Postgres with high availability (RDS).
I haven't had a single second of downtime since I migrated [4] (I up the status dashboard a few months ago, but moved to AWS earlier than that.) Convox supports auto-scaling and rolling deploys. It waits for the web process to be healthy, and if something crashes it rolls back the deploy without any downtime. I can also terminate any instance at will, and another one will pop up to replace it with zero downtime. After using it for the last ~6 months, I feel confident enough to start offering a 99.999% SLA.
[1] https://formapi.io
[2] https://formapi.io/templates/tpl_DEMO42TmQjTgsQ7q/edit
[3] https://convox.com
[4] http://status.formapi.io
[+] [-] motohagiography|7 years ago|reply
Chose both because I wanted consistency between the abstraction of my business logic, and the spec of my implementation.
I get some chippy guff about using graphs, but by taking the time to define my business logic as a grammar, expressing that grammar as a graph, then implementing it directly into the model, I get a lot of "aha," moments from potential customers.
Graphs can be analogous to functional languages in that if you are using them, there is a higher likelyhood you've reasoned something through before implementing it.
[+] [-] Klonoar|7 years ago|reply
Partly because I'm apparently a masochist, but also because... I mean c'mon, modern architecture is CRUD and job queues. Rust can do that fine if you don't get distracted by the bells and whistles.
I ripped out and open sourced my user-module stuff for authentication handling, if anyone's interested: https://github.com/ryanmcgrath/jelly
[+] [-] raarts|7 years ago|reply
Why? For me it's best of breed vs simplicity. OpenID Connect is the most mature auth, rabbitmq very good messaging, elixir a lovely language, graphql the most programmer-friendly connection between frontend and backend, and react native allows 90% code sharing between web SPA and mobile apps.
And if you combine all of these (I mean if you finally set it all up), it's a low number of lines of code environment.
[+] [-] mindcrime|7 years ago|reply
All of that said, I'm a big believer in "use the right tool for the job" so if something comes up that requires C++, I'll use C++. If something needs Python, then Python it will be. If Prolog is right for something, I'll use Prolog. Or COBOL, or Erlang, or Ruby, or CL, or Perl, or SNOBOL, etc., etc, yadda, yadda, ad infinitum...
[+] [-] duncan-donuts|7 years ago|reply
[+] [-] leon_sbt|7 years ago|reply
Front-end: React SPA (Via Create React App),Redux, React-Bootstrap Why: I had no prior framework experience, single command setup, and plenty questions on Stack Overflow and Medium articles to learn with. Going the plain Javascript route with no frame work,seemed like I would be on a slippery slope for spaghetti code down the line. React's one-way data flow and component architecture made things incredibly easy to mentally digest. I found React's documentation VERY well organized and explained, and Vue's documentation was intimidating when compared to React.
Version Control: BitBucket Git Why: Free private tier for solo use and enjoyed previous experience with Atlassian products
CI/CD: BitBucket Pipelines Why: Already using Bitbucket, this just worked seamlessly with it. Only $10 for 1000 more build minutes.
Firebase: Hosting/Cloud Functions/Firestore/Auth Why: Everything is automagical HTTPS static website hosting for the create-react-app (This is what first got me started) Then came Storage,Firestore,Cloud Functions, and Auth. Wish it had an automagical SQL product. Low Entry Cost
Cloud Provider: Google Cloud Why: Had no experience with any cloud provider. I found the pricing/product offerings really easy to digest and interpret when compared to AWS.
Email Sender: Sendgrid Why: Good starting free tier. Decent Docs. Easy to setup.
Backend Compute: Google Compute Engine +Docker+Python-based API app Why: I can do local dev easily with Docker, push the image to Google Container Registry, then pull the image to the VM. It's easier to do than learning to setup a CI/CD piped GKE cluster Eventually I want to pay the "tax" go to a GKE CI/CD Kelsy Hightower setup,so I can git push/PR/merge a change, and it's in production. I don't do enough changes to the backend right now to justify a CI/CD piped GKE setup.
Other: Email Client: Gsuite Why: Custom Domain Name I'm already familiar with Gmail
Project Management: Trello Why: Integrates with Bitbucket Multi Device Support (Phone,Tablet,Desktop) Easy to mind map and organize features
What I value: Good Docs Free tier for solo devs/low use, and progressive options for paid plans (Gives me breathing room on cash while I figure things out) Lots of questions/answers on Stack Overflow or in-depth Medium articles.
[+] [-] im_cynical|7 years ago|reply
Python for the backend under the argument of "build using what you know". ReactJS for frontend development because Python for frontend work I find very antiquated.
Architecture wise I'm hosted in AWS. Data is stored in MySQL and Redis. All self hosted because I'm to cheap to pay per request pricing and the overhead is very minor when done right when rolling my own
[+] [-] RandomBK|7 years ago|reply
[+] [-] noncoml|7 years ago|reply
I am not making fast progress, I think the problem is my keyboard, I should try buying that Ducky one I have been eyeing for quite a while.
[+] [-] passivepinetree|7 years ago|reply
How do I separate what might be a side project to learn a new stack from a side project that might eventually make money?
[+] [-] jdietrich|7 years ago|reply
Before you write a line of code, make a clear decision as to whether it's a learning experience or a business venture. Plan your project based on the goal you've chosen. If it's a learning experience, consciously avoid doing anything that doesn't push you to learn something new. If it's a business venture, consciously avoid doing anything unless you believe it has the highest RoI.
Some purely recreational projects do turn into viable businesses, but far more projects have failed due to indecision and yak shaving. If you're building a business, you don't gain anything by experimenting with a new stack. If you're learning React, you don't gain anything by writing a bunch of CSS and marketing copy. Don't be afraid to step away from the keyboard and ask yourself "Is this a good use of my time?".
[+] [-] Mc_Big_G|7 years ago|reply
[+] [-] losvedir|7 years ago|reply
[+] [-] clintonb|7 years ago|reply
[+] [-] i_made_a_booboo|7 years ago|reply
Also build using what you know isn't always the best advice. Figure out what you want to optimize for and optimize for it. That may include doing things in a different stack.
[+] [-] 1996|7 years ago|reply
[+] [-] berti|7 years ago|reply
[+] [-] tephra|7 years ago|reply
Apps: Flutter and if I need it switch to native. But flutter is really good for my simple needs!
[+] [-] sorrymate|7 years ago|reply