| Ah, interesting! Well, you've done some homework already and defined the problem area quite well, so you have that going for you. C and C++ aren't the easiest languages to learn given they require manual memory management, so you have it fairly easy learning something else, unless you actually want to use C++ for the backend (I would hesitate a lot to recommend C). The main advantage of using something like PHP/Python/Ruby/Node vs C++ is the nonexistent compile times, along with the fact that they're all much higher level and let you focus on your app's requirements. That said, no language is perfect; it's about picking the one you can live with the easiest. Another potential consideration is to choose a language that a lot of programmers in your area are familiar with, so that you have a competitive market to take advantage of if you need to bring in extra help. I'd say that it would be significantly easier to not spin this a general-purpose SaaS stack, but instead build this as a bespoke system specific to these plants' requirements. It will make developing the system significantly easier, especially given that this would be your first major project. Practically every enterprise/environment is full of custom applications; these are not unique at all. (That said, from an educational standpoint, thinking about how you might generalise what you build would be a good idea, and serve you in building similar systems later on.) Assuming you haven't already done this, what you definitely need is information about exactly what everybody needs to be able to do. You have an absolutely excellent opening with the fact that your Dad owns one of these plants: you should be able to easily get access to wander around your Dad's factory and ask questions of everyone when they have moments of free time. I would strongly recommend having long conversations with the workers themselves and completely hearing out how they would solve the issues they have on the floor. Potentially be prepared for the application to suddenly become very different than what you planned :) - you may end up electronically enabling/adding brand-new functionality to these plants' capacity/capabilities alongside the analytics and number crunching features you initially started out with. It might be a good idea to do several rounds of questions, as you can discuss things in greater depth as you internalize what you learn and come up with unknowns as you work out how to turn problems into helpful code. You may or may not find asking questions helpful at the point you're at right now. Maybe an idea to discuss with your Dad. As for an immediate long-term goal to figure out how to reach, I'd suggest taking the architectural requirements you have thus far and going ahead and figuring out how to put together a system that provides those things. This might be an existing system you buy (although I would strongly recommend grabbing some freelance consultant help for an independent go/no-go if you think about this route) or an open-source software stack that you can start with, or a stack you build yourself from scratch. You may need to go through several iterations of designing, spending long days and nights on building, and then realizing you have to throw away half the system and start again. This is not a bad thing; in fact right now I'm building a crawler for a specific website that I'll use once and throw away. It's gotten to a couple thousand lines of code right now (it's quite simple, but PHP is quite a verbose language for async network stuff, and I'm unfortunately yet to learn a better language like Go or Python), and I'm basically putting it together for this once-off use-case. I've mentally saved a LOT of valuable information about Web crawler design that will go into my next major project, a more general-purpose crawler (note the things about generalization I mentioned earlier). I couldn't get this info from reading tutorials or even academic papers or theory. Oh, another thing - databases are weird and annoying, but I would highly recommend you learn them in depth. There are lots of choices; MySQL/PostgreSQL are the de-facto relational options (and for MySQL there's phpMyAdmin, which is awesome for mental modeling and simple setup); Cassandra scales out to a staggering level; SQLite3 is great for learning on and prototyping with; MongoDB comes with utterly insecure defaults and doesn't scale well but does kinda work (not dissing it, just being honest). There are many others. Query plan optimization is something that should be absolutely logical but is full of obscure edge cases, and writing the same query with different syntax sometimes gives inexplicable speed boosts. Lots of confusing fun - my point is figure it out to the point where you're comfortable with databases and can easily reason through them. You probably discovered http://stackoverflow.com/ long ago; if you don't already have an account with a few hundred reputation I would recommend going on there and answering a few questions so your account has enough reputation that you can do things like use chat and such. Some of the other Stack Exchange sites like http://codereview.stackexchange.com/ may also be of help. Good luck, and I kinda want to hear how this goes :) |