@DetectiveClayton
Remember, none of us have ever done anything like this before. Except for Mike, who once stole a tank and invaded Paris.
PHP, Drupal, Linux. More comfortable at the command line than the GUI. Nano, then Vi, then emacs. 10 years on the Shetland Islands may have made me more than a little strange. Husband, father, dungeon master, chef, baker. Here's a d20, now roll for initiative!
Nothing here yet.
No blogs yet.
Comment your code - not for the benefit of other people, but for your own benefit a week down the line Your site will never look 100% the same across all platforms, so don't worry too much about it (no-one uses Internet Explorer anyway) Today's shiny is not always going to be around, try to make sure you don't back the wrong framework Back end styling is just as important as front end, especially if non-developers are going to be using your work Learning the command line tools is never a waste of time
We've a mix of internal and external hosting. As I'm a department of 1, I want the security of knowing there's someone out there looking after our stuff in case of emergency. Over the last bank holiday weekend, PHP on our main internally hosted webserver decided it wanted all of the CPU and no, it wasn't going to let go. Our alerting system let someone know it had happened - not entirely sure who as I didn't get anything. Finally found out there was a problem at lunchtime Sunday when I picked up a Facebook messenger message! Long story short, if there's a team of you, or it's not mission-critical, host it internally. You'll learn loads and get the chance to work with software you might otherwise not get. I've got a collection of Raspberry Pi boxes as development and testing servers. If there's a team of you, and you've a good rota for emergencies and monitoring, host the critical stuff as well!
And they laughed when I wrote the disaster recovery plan for our server room and included flood risk! We were only 6 feet above sea level! As far as I know, it hasn't happened yet...
Ah, I see. Well, knowing the dimensions of the graph/s in question I would replace the empty graphs with a DIV of identical dimensions and a simple "No data available" message. Or an image, perhaps with faded-out graph in the background, of same.
If there's no data, I don't show the graph - a simple message to the user saying "No data is available for the selection you have made" or words to that effect. Usually in the div that would've contained the graph had a graph been available. If it's all done via ajax, then the message gets shown in a modal over the page and the graph is left in it's default, empty, state.
As a rule, I'd want to know one client-side language and one server-side. With Node, JavaScript blurs those lines. But as others have said, it depends entirely what you're wanting to do. Pretty much anything web-based, you won't go wrong knowing JavaScript. And even knowing a little will mean that you've a better understanding of what those jQuery libraries you're importing all over the show are doing for you - and how you can make them work more to your advantage. Away from the web/desktop/etc, knowing JavaScript would help you with Node-based things, Tessel, that sort of lovely kit. But not a lot more that I can think of right now. The big advantage of knowing any programming language is that it gives you a better idea of what most other languages are up to when you sit down and try to learn them. You're already thinking like a programmer. Unless it's WhiteSpace or some similar esoteric wonder, in which case all bets are off. So, must-learn ? No. Useful? Definitely. No knowledge is ever wasted.