What to start learning?
-
So I am in my mid thirties and a COO of a small business. Way back when in High School I took some programming classes and loved it. VB6. Fast forward to college and started in computer science before I hated a few professors in a row and switched to business school. So In ever followed through on what was my intent at that point of being a programmer / developer. Now, I see a real need for my business for a centralized application that can handle a multitude of things. Basically, we are a very unique company and not out of the box software fits all of our needs. I am realistic and I know I am not going to create an end all software application for my company. I totally get that. This is a side hobby for me (and I have kids too so we'll see how much time I have). BUt I have always loved problem solving, computers, and the thought of programming really intrigues me. Since I knew VB6 (based on high school classes, far from an expert) I am inclined to think VB.net is the best place to start and learn. But for me to learn through a project, if you are recommending to a newbie who wants to dabble with one application and never do this for a living... What would you recommend to them studying, learning, and playing with? It would need to be a database application too so that factors in. Web or desktop I dont know. I am inclined to think web takes so much of the complication out of connectivity and end user experience. But is it powerful enough to really do thinks. Here would be my start: Right now we take meeting minutes manually in a word based template. This software would have data entry for the minutes, keep it organized, and automatically distribute to all participants after the meeting. First feature. Second feature is a shop drawing log and submittal tracker. So when we make something custom, we prepare a detail drawing. Send it to an architect for approval. When it is approved sned to the manufacturer to release into production. Track all of these submissions etc. That would be number two. I would start with those two small features and continue slowly to add one at a time. Just a slow release of new functionality as our team realizes they need something. Recommendations?
All of what you describe is readily available on the internet on a "subscription" basis; usually about $5 per month: Collaboration and / or Document Sharing. One could be up and running in a day or two; develop it yourself, and it may never get done. I recommend these solutions to clients and then bill for support; doesn't pay to "develop" these services.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
Thanks, and thanks to all who are responding. Generated way more conversation compared to what I expected lol. To summarize for everyone (in terms of my capabilities) I spent some time with VB6 and later played around with VB.net and database connectivity. I certainly understand OOP and basic concepts and brushing off some dust can handle some code in VB.Net so I am not just learning from the ground up. I have never developed a full enterprise level piece of software nor am I truly expected too. I really want to just create some isolated functionality that is not available in out of the box solutions so I can incorporate it into. With that being said, it sounds like it would be time well spent to transition to C# for further future experience and there are just better resources out there for help. What are thoughts on backend support? Maybe while it is very limited I am just better off on using access and keeping it simple and scaling it up eventually? Is it feasible to use a database on office 365 so I dont need VPN connectivity to my office?
If you need more power, ASP.NET is used as a backend support for C#. It is used more for WPF for more complicated GUI's. You can start with Windows Forms for more simple GUI's.
-
Not ignoring this at all. I think there is a LOT of merit to this for a few reasons..... 1. Realistically will I ever get to really build this thing, probably not. So if I ever decided to go the custom route I have a good benchmark to share with a developer on what I am looking to accomplish. 2. I do agree as anytime I have dabbled in coding I just start, and quickly it starts to expand into needing this and that and the other thing and it loses focus. Giving myself a road map would be helpful. So I might go this route.... What do you typically do? is it a narrative summarizing the workflow? Picking out the nouns as my classes and my verbs as my actions? How do you actually map it out? Is there a decent piece of software that helps visualize it all vs just trying to type it in word?
My favorite modelling tool, the age-old ER, Entity-Relationship model, focuses strongly on the information structures, rather than the workflow. It is essentially a semi-formal drawing technique - and of course there are a number of "dialects". Some computer based tools are available, often forcing you to use a specific dialect. The one I have used most recently is called yEd[^] - it is not specifically for ER, but supports it well. An ER model is a graph with "entities" (data objects) forming the nodes, drawn as rectangular boxes. Actually, the entity is like a class definition; a "customer" entity is any customer object. Relationships to other entiries are edges, drawn as arrows. Arrowheads, both ends, indicate how many objects are involved in a relation: A "bill" object and a "customer" object has an n:1 relationship, indicated by different heads. Notation exists for "0 or more", "exactly 1", "1 or more" (more specific cases, like 1 to 3, is indicated textually by the arrowhead). For straightforward relationships, a textual label on the edge is sufficient it is always double, indicating each entity's view of the relationship, such as a customer "bought" what the bill specifies; this "was bought by" a customer. If you need to handle data about the relationship itself, which are not properties of the entities (such as the date when the relationship was established), or a three way relationship (such as who endorsed it), you can draw it as a diamond with arrows to two or more entities, and attributes associated with the relationship. Two entities may have several distinct relationhips. Often, splitting up a diffusely specified relationships into distinct one can be enlightening, e.g. "business connection" going to "Buys products from", "Provides programming services to" and "Owns shares in" - different procedures will need to relate to the relationship in different ways. Entitiy attributes are either, in simple models, drawn as ovals attached to the entity, or, in larger models, listed inside the entity rectangle - this illustrates one dialect variation! Another variation (more in modelling style than language) is how much you break down complex data into distinct entities: Is a "car" one single entity, or should you split off an "engine" entity with an "is powered by / powers" relationship? If otherwise identical cars differ only in engine selection, and/or each e