3 ms·

> - You realise that you are not sure how to deploy this on production. My advice for this is don't worry about it. Just hand install on a cheap shared web hos

> - You realise that you are not sure how to deploy this on production. My advice for this is don't worry about it. Just hand install on a cheap shared web hosting place and manually copy stuff across to get it up and running. When that gets too annoying, start automating. When your home grown automation scripts get long and unwieldy, look into Capistrano or Puppet (or Chef, or Ansible). The important thing is: make it work first, then make it beautiful. > - You realise that you will need a business model and you are just a developer/designer and have no idea about those. I feel you there! :-) Having an idea and trying to think of how to get someone to pay for it is daunting to me. I feel like a blank canvas and I have no idea where to start. > - Then comes the tax issues, and realisation that you need a company. Again, don't worry about it. If you make so much money that it matters—well, that is a good problem to have. You can always incorporate (or whatever) later. And if you're pulling in a lot of money you can afford a lawyer to just handle it all for you. - You don't know how to licence your idea/project If you're making a web site or a app store app (binary distribution) then again, it doesn't really matter. If it becomes so wildly popular that people start abusing it somehow, and in quantities that matter—again, that's a nice problem to have (compared to no one using your site or app). If you're releasing source, then pick MIT, BSD, or GPL (just choose randomly if you have no opinion). If the one you picked turns out to have side effects that you didn't foresee, then feel free to change it–it's your code after all, so you can do what you want (though if you get a whole bunch of external contributors, it gets hairier). One thing I've found that really really helps—get a partner. Having another person around (and not necessarily physically) is a great way to help keep you from getting distracted. This is why companies get stuff done—there's always someone around working and you can't just slack off without losing face to everyone around you. It's really hard to sit around and read reddit all day when the 3 people in the room with you are all working hard…

whizzkid 13y ago
Except the first one, thanks a lot for looking at the bright side of things and the advises! but.. How can i not worry about deployment? What happens after people trusting and starts using my 'lets say' web app and after 2 weeks i get my database hacked? Companies have TechOps department just for deploying the applications correctly. I am not trying to argue but trying to explain how i think of this :) Maybe i am being little bit too much paranoid... Should i just set Apache/Passenger with some basic configuration and wish that everything is safe enough ?
- __david__ 13y ago
  Again, I wouldn't worry too much about getting hacked. Don't use bad or obvious passwords on your db or ssh account. Besides I would say much of the hacking surface is going to be in your site's code, if it's in any way dynamic. You'll probably make mistakes. The biggest actual devops advice I can give is backup. Everything. Often enough so that if you lose everything since your last backup you can live with it. And again, it doesn't even have to be automated. Run mysqldump by hand and save the results away somewhere. Rsync your home directory away. If you have a dedicated server, rsync /etc, too. Having a backup is the solution to almost any catastrophic event in the devops world. Disk crash? Get a new disk, restore from backup, continue on. Hacked? Figure out how, fix security hole in code (or wherever), wipe server, change passwords, restore from backup, continue. I'm sure there are more. Having done devops work, most of the hard part is getting it to all run smoothly and automatically (big web sites have many many servers and slave dbs, and deploying to them all becomes complicated). But as a single person working on a small project, that's not the most important thing to optimize for, in my opinion. It's more important to get it done.

whizzkid 13y ago

Except the first one, thanks a lot for looking at the bright side of things and the advises! but.. How can i not worry about deployment? What happens after people trusting and starts using my 'lets say' web app and after 2 weeks i get my database hacked? Companies have TechOps department just for deploying the applications correctly. I am not trying to argue but trying to explain how i think of this :) Maybe i am being little bit too much paranoid... Should i just set Apache/Passenger with some basic configuration and wish that everything is safe enough ?

__david__ 13y ago
Again, I wouldn't worry too much about getting hacked. Don't use bad or obvious passwords on your db or ssh account. Besides I would say much of the hacking surface is going to be in your site's code, if it's in any way dynamic. You'll probably make mistakes. The biggest actual devops advice I can give is backup. Everything. Often enough so that if you lose everything since your last backup you can live with it. And again, it doesn't even have to be automated. Run mysqldump by hand and save the results away somewhere. Rsync your home directory away. If you have a dedicated server, rsync /etc, too. Having a backup is the solution to almost any catastrophic event in the devops world. Disk crash? Get a new disk, restore from backup, continue on. Hacked? Figure out how, fix security hole in code (or wherever), wipe server, change passwords, restore from backup, continue. I'm sure there are more. Having done devops work, most of the hard part is getting it to all run smoothly and automatically (big web sites have many many servers and slave dbs, and deploying to them all becomes complicated). But as a single person working on a small project, that's not the most important thing to optimize for, in my opinion. It's more important to get it done.