|
So....no Mongo love?
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
I'm tempted -- I mean I just adore the default high-security settings!
It needs a good poke.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Default settings are for victims.
"There are three kinds of lies: lies, damned lies and statistics."
- Benjamin Disraeli
|
|
|
|
|
Nathan Minier wrote: Default settings are for victims.
Literally, given the number of bots poking mongo installations.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
So the general thought is PostGres or MySql for a database back end?
If, and that is a big if, this ever became something we really were able to roll out and use we could be talking about 40 people accessing data. So not thousands, but not two. I have done visual basic connections to access in the past, and thought about that route (as this is a simple application at least at the onset) but figured if I start with a bit more capability, I might be WAY better off long term in terms of conversion.
I also was tempted to just look into azure or something like that so it is a hosted scenario elsewhere and I pay Microsoft to handle the BS. I just need to connect to it and that way people that travel dont need VPN to connect to the software and if I get web based I dont have to deal with hosting and security issues.
|
|
|
|
|
 You still have to deal with security issues, regardless of where your data is hosted.
|
|
|
|
|
Member 13044355 wrote: Recommendations?
If you think it's expensive to hire a professional, wait till you hire an amateur.
Great that it's your hobby - keep it that way and get a real pro in to do a proper job - it will save you money and heartache in the long run.
If you do insist on going down the road, use c#.
Good luck.
|
|
|
|
|
Absolutely. Great that you have an interest in programming, definitely go for it as a hobby if you have the time.
But do NOT write software for your company that it will depend on, or whose failure could cost the company time. The company is not only YOUR source of income, it's the support for your staff. Do not lumber your "baby" with software written by a beginner. You'd no more do that than take time out building offices for your staff with no prior experience. Either hire a permanent, experienced staff member or work closely with a reputable freelancer. Get as involved as you like (but don't take your eye off running your business). Learn from them and by all means get involved in the process.
Otherwise, not only do you risk your business but you also probably lose your hobby, as you will be frustrated and come to hate software development as you see the damage it's doing.
|
|
|
|
|
Well the challenge is purely the cost. Exploring the custom software route looks like a FORTUNE.
Again, will this ever be something the company really utilizes. I dont know. Just something I have always enjoyed doing and wanted to learn more. So rather than dabble on just bs tutorials out there I thought it might be a bit more enjoyable and a learning experience to attempt to do something useful and purposeful for my "day job"
|
|
|
|
|
A understanding of data relationships and database structure is critical. If you get this wrong you will come up limitation and pain later on.
However you will want to play in both the database and development app side so I would recommend c# rather than VB.Net. There is nothing instrinctly wrong with VB but c# does provide a better foundation to other languages and techniques in the future. The learning curve to C# will be slightly more thn VB, but will be worth it in the long run.
Start small and concentrated on the basics first and if you're learning from scatch, be prepared to rewrite it later with the better coding and database structures etc you pick up over time.
|
|
|
|
|
Member 13044355 wrote: very unique
|
|
|
|
|
As others have intimated, study your data and get that correct first, then hire a professional to do the job.
I would recommend that you pick a smaller hobby project, or even an obscure but small part of the overall project to do your learning on. Use your growing knowledge to learn from and oversee the professional.
As the COO of the company you should have neither the time nor experience to do this job, it will never come to fruition and you will have wasted your time to no benefit to the company.
If you have identified a need for an integrated system then budget it and move forward, don't piss about trying to fiddle it yourself.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Learn C# maybe with the focus on Xamarin for mobile platform. The are a lot of tutorials in web - some for free but think about a paid plan to get serious.
The all important question is for what or whom do want to make software?
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Member 13044355 wrote: Recommendations?
Angular 24 would be a good start. It should be out by the time you make coffee.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
By the time he drinks it there would be already Angular 29.5
* CALL APOGEE, SAY AARDWOLF
* GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
* Never pay more than 20 bucks for a computer game.
* I'm a puny punmaker.
|
|
|
|
|
I'm quite sure that you are not going to follow my recommendation (noone does!), but I'll present it anyway:
Forget all sorts of coding for a while. For quite a while! All about VB, C#, SQL, ... Spend a lot of effort on exactly defining your tasks, and the information you are handling. How one piece of information is tied to another pice. Which is the 'master', which is a copy of a master, or derived from some master(s). Which information is required by which tasks/operations. All that is comes under the umbrella "Data modelling".
Try to stay away from putting it into code (including SQL) until you have a good, complete understanding of all the information you are handling in your business. You may use formal or semi-formal data modelling methods (I am myself very fond of Entity-Relationship, ER, due to several very succesful projects using ER - but it isn't exactly fashionable today!), but a less formal method is still a lot better than bringing in coding languages.
Once you have completed the data model, with all sorts of relationships and restrictions, and described how your procedures use and manipulate the various data entities, writing the actual code is a job for an inexperienced teenager  . (That is to say: All the difficult problems have been solved before you start coding.)
Most people grin at such proposals: Of course we already know which data we are handling. We know where we need the data! ... But that is until you start creating a data model. As soon as you start asking details about which entities may be multi-valued, why seemingly the same information appears in two places in the model, which is the primary value, which are derived values, why an operation addresses entities from different parts of the model where you have not identified a relationship between them, and so on. Several times I have had people with 20-40 years of working experience in their professional field light up: "Is that how it fits together? Yes, you are right!" They have seen all the trees, but never considered the forest. That's what data modelling is for.
Understanding the problem you need to solve before you start solving it definitely not in the modern 'agile' style. Nowadays, people say: "OK, so you've got a problem. Let's first start with 'int main(int argc, char** argv) {}' ...Now we are going at it! Will you try to describe your problem, and I can jot down some rudimentary code for solving it, as you are talking, and we will fill in more code as the problem becomes clearer."
That's the modern way. The one I recommend you NOT to follow. Thoroughly understand your problem first, and find a solution at a conceptual level, independent of any specific coding language. Only then start coding. That is just a small, menial job that is not very exciting. The exiting part is understanding your problem and its solution.
|
|
|
|
|
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 engine has a number of reationships to other entities, such as "Used fuel type / is used by", splitting up may be a good idea, but going too far increases the size of the model too much.
Many ER models include all entities relevant for a business (or whatever) - including non-digital ones. A car entity may be physical; the driving log may be computerized, but the driver identified in the log is a human. If you need to refer to that car, or that human, you need to represent them by selected attributes in e.g. a "personnel record", but entire sub-networks may remain as non-digital entities.
When you have identified all your data (typically ending up with 10-100 entities, and a relations count in the same range), you try applying operations (or workflow, if you like): Draw a closed curve around those entities you believe are required, and "simulate" the operation: From which entities do you obtain information (including which relationships to follow from the starting point)? Which entities do you modify? Do you have all data required to do that, or do you have to bring other entities in? Do the lookups / modifications reveal that there are relationship that you hadn't thought of? (there always is, early in the modelling process!) Are some enties that you included inside the curve not really used, so the curve can be changed, leaving them out? Are all the entities referenced available digitally?
ER does not define any (semi)formalized language for describing the operations, you do that in as informal or formal text as you choose. In the ER spirit, you put a lot of logic understanding into the relationships. The procedure description really add very litte semantics; they just select which semantics to use for the operation. If you need to read the code to understand how things fit together, then you probably are missing a relationship in your model!
(Note that this is a quite different philosophy from an SQL data model, where you treat data as "pure data" which represents nothing but its own value, and all the semantics lies in the procedures. But then: ER is a conceptual modelling tool, SQL is an implementation tool.)
My experience is that the users/customers are able to relate to, and discuss, entities and relationships. You can't slam a hundred pages of SQL code or C++ class definitions on the table, but you can display a 50-node network of entities they recognize from their traditional operations. With an ER model, you get feedback from non-programmers. Non-programmers never give you feedback on SQL procedures!
Some ER drawing tools have functions for transforming an ER model to a e.g. a set of SQL tables, one table for each entity (class) and relationship. As with most code generating tools, the product may be messy and unreadable, but you have to comprehend it to write the SQL operations on it. Often, the ER tools enforces implementation requirement on the conceptual modelling, such as requiring you to identify a 'primary key'. Usually it requires you to implement all code in a single language. And they take for granted that all entities are digital, and you want a single digital model for the entire model. (One of the models we build was for all the entities of the public administration of our city, 100+ "main" entities, a fair share of them non-digital - you would never make one single application, not even a single database for every single operation of a 200,000 size city!)
Briefly stated: I don't like those generators. I find it easy generate by hand the required class definitions, or whatever it is called in the language selected, and then I can select those entities needed for a specific operation. Some of them are database tables, some of them are not. Generating by hand gives a lot better readability, more flexibility e.g. in choice of language etc.
I've written too much already... It is impossible to give an ER crash course in a forum thread. But maybe this gives you some idea of what ER modelling is about.
|
|
|
|
|
and do something with an arduino or a raspberry pi
|
|
|
|
|
You really have two questions: "What should I learn?" and "What does my company need?"
I applaud your interest to return to your early ambitions of programming. Despite what people say, it's never too late to learn. I would recommend Python as a great place to start. Simple but powerful.
But that's not what your company needs. You say your business is unique, but what you have described are generic business needs that just about every company I know needs to address in one form or another. There really are tools available. Investigate the Atlassian Suite. (Confluence for meeting minutes with auto-distribution; JIRA for issue tracking and workflows). Both are very reasonably priced for small teams.
|
|
|
|
|
I would recommend you download: Jobs Site Starter Kit for ASP.NET 3.5 | BinaryIntellect Knowledge Base
It is very well organized and allows you to quickly learn about Business and Data Object Layers, as well as persisting data to a SQL Server Database. It's VB.NET so would be more familiar to you. At this point I think it's more importante to learn about concepts and technologies, like OOP, Layered Arcitecture, ADO.NET, SQL Server etc. Once you master this, it will be relatively easy to learn C# as well. Having said that VB.NET is far from being dead or inferior to C#. Read up about it on Google. There may be other Starter Kits where you can learn about what I pointed out above, but this is one I checked out myself years ago and it helped me a lot to see how things work in real (programming) life.
The perfect woman: cooks good food and never says no in the middle of the night.
|
|
|
|
|
I am a programmer myself. I strongly recommend C# for your immediate needs. You will find that it is similar to VB in some ways which will make your older experience relevant. Furthermore, C# is strongly typed and typesafe so it is much easier to debug than many languages. C# is well documented and therefore very easy to re-learn programming with. This language can also be used to easily develop the types of applications you are referring to in your post. To top this off, you can get a free compiler from microsoft to get started, so you don't really need to invest a lot of money to get started learning.
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
