|
I'm not sure that what you are describing would be a practical problem to solve, for multiple reasons. The biggest issue I see with your problem is what effect pulling the code across from user 1 to user 2 would have on the code that user 2 was working on; they would either have to copy the whole codebase to a whole new area on disk because any changes might conflict with work that user 2 was already doing, or they would have to merge in the changes into their codebase, resolve any merge issues and then start the code review process - but you're talking here about multiple users all working with the same codebase, presumably submitting back to User 1, so how would these changes be resolved, where multiple solutions have to be merged back - (1 to n isn't that hard, n to 1 would be an absolute nightmare)?
There are already tools that allow you to stash work that you are working on and let others take copies. You can use GIT (for instance) to stash your work and let others take copies - which could then be worked on, reviewed and merged back in, in a controlled fashion. Unfortunately, this doesn't meet with your realtime collaboration goals but what you could do is combine GIT with something like Lync (yeah, I know, it's not the greatest collaboration tooling but it's an idea), and then have the users discuss changes online with one user making the changes while the others watched and talked things through; this would be a form of pair programming.
This space for rent
|
|
|
|
|
Thanks Pete for the answer!
Due to some lagging on the website, I didn't see your reply (or my question for that matter) until I had just posted an updated version of it on General questions. As I don't think I can erase a question, I'll leave it there (I'm not sure this forum was the best place for it anyway).
Anyway: well, I wasn't really thinking an n:1 thingy.  Rather something like this: I am working on a song in some music software. I could really need some help on volume levels and the like. Instead of copying the entire file plus included audio files somewhere, having someone else downloading it, and then trying to find out what the other person has done to it, it would be much easier if I could just find a list of (visible) online users within the software, send a PM to one of them and ask him/er for advice. He/she would then just click a button in the software to download my files, and then being able to make changes to them. That's the idea anyway.
Thanks again,
Petter
|
|
|
|
|
|
You're right - screen sharing would make this easy.
Thanks!
|
|
|
|
|
petter2012 wrote: this should just be a way to have several people looking at and working on the same files
I doubt that is workable. The situations where that specifically is used would be so rare that it isn't useful.
In normal situations there are two actual peers, each with about the same experience and one needs a 'tweak' to get around some problem. In those cases just seeing the code and doing a verbal walkthough is sufficient. There are many existing solutions that allow that.
The second case is where the first person is a junior and the second, the observer, is a senior. In that case although the second could write the code the complexity means they would need to test it as well. As such they might as well write it in the first place. Not to mention that the first person loses out on the learning opportunity.
petter2012 wrote: So, is there any software that would take care of this and serve other software with a suitable API?
I would be really surprised if there are not open source collaboration tools. Since they are open source the code is available to you to do what you will.
|
|
|
|
|
I am looking for suggestions to develop a back office business system for a family startup. Specifically a programming language that will meet the needs of the business. I have already laid out the design concepts, data structures, etc.. I envision 10 - 15 thousand lines of code to start and it will grow to about 50 thousand. The will be very limited access to this data via the web.
The requirements are:
1. Target operating system will be Linux - probably Ubuntu/Mint.
2. Language must be strong in data structures and I/O to handle sequential, text, direct, and index files. I do not want to get into writing my own indexes and access methods. Been there done that.
3. Must be compiled. Scripted languages can be hacked where compiled languages are much harder to hack. Source code will be kept far the the web.
4. I don't mind if the language has OO constructs but do not want to be forced into using them. From my experience OO the hinders more than it helps. It's like putting handcuffs. The shorted distance between two points is a straight line. That's a personal requirement.
I know the list isn't long but I could be missing something out there I don't know about.
Thanks...
|
|
|
|
|
C or C++ will do the job.
|
|
|
|
|
... and about 10 years of previous applications development experience if one expects to deliver this sometime in the future.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
C is a possibility that I am going to look into. When I was doing C on ATT Unix V it had poor i/o support and had to write dozens of B-tree structures to support the businesses data and users.
But I think it has an ISAM/VSAM library now. Need to look into it. Don;t really want to get into that again - it's a bit of code to do.
Thanks
|
|
|
|
|
If you want a simple database then SQLite[^] may be a good choice.
|
|
|
|
|
It's a good idea but down the road there are going to be needs that go beyond the shuffling of data.
And it is just me - I like everything under one roof (one programming language). It's just easier to deal with. Thanks.
|
|
|
|
|
VSAM is the underlying file structure for IBM's database management system. As far as I know, there are no other implementations.
You're either using a bot to "spin" this stuff; or you've just woken up from a corporate sleep.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Joer4x4 wrote: Must be compiled. Scripted languages can be hacked where compiled languages are much harder to hack.
You mean compiled to native, not to bytecode. If you want to know "how much harder", then go take a look at the amount of games that were available in the '90s without a copy-protection in the wild.
Joer4x4 wrote: From my experience OO the hinders more than it helps
Makes me conclude that your experience is too limited. OOP does not shine in small utilities, it shines in larger projects. Don't tell me you'll be favoring global variables too.
Joer4x4 wrote: I envision 10 - 15 thousand lines of code to start
You don't know what language, nor how tense that language is, but do already know the LOC?
For any experienced and inexperienced programmer I'd recommend C#. Yes, compiled, but not to native. If your application only runs on your machine, then that should not be a problem. If your application is distributed in the wild, then preventing hacking becomes a mere economical question. Most applications are sadly not worth the effort of stealing
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
1. Does not have to be compiled native so long as I end up with machine code. This isn't a game it's business - totalyl different ball game.
2. I can write a system faster in older languages with OO. If you look closer and understand the languages it becomes obvious that OO is not completely new. Older languages have been doing that stuff long before OO. The difference is they gave it fancy names and made the programmer write code to restrict and enforce the usage of data. Every time you pull data together to form a record you encapsulate the data. When you pull the record inheritance is automatic. The data is what it is. But if you are pulling for a different purpose you have to jump though hoops so OO will let you use it. Without OO it can be easily accessed and broken for the need. The focus should be on the data and purpose - not the language. A single variable name is easier to follow through a program than 20 variable names for the same thing.
We all know a fence belong around buildings and homes and is built on the ground. It works fine for OO but down the line you may need a fence for your model train set so now you need a fence on the table. Now what? Create more unnecessary so it suits the language because to get that fence? In the real world you need to be prepared to put a fence anywhere. Why? Because you can and the business wants it yesterday.
There was a time when many business(even small) had there own programmers. They wrote software that gave the business and edge over the next guy because it was tailored for the business. When OO came along that faded because OO became expensive and not as much was getting done. It was not all OO but it helped. Now it's a package world - one size fits all but it doesn't really?
Hey if you like OO go for it. But having experience both worlds - I'll take the old one - much more efficient. Especially in large projects. If done right and understood OO does not make better code or a better programmer.
3. I know what language but I am avoiding it. While I am exploring I understand that most most new languages were developed by those in research, science, and some back office at some university. Unfortunately those languages tend not to be business friendly especially in the the area of file I/O because they built the language for their needs and not the needs of a business. C is a prime example. They needed something better than B to build Unix. So C was born and is a great for building OS code and utilities. For business it will work and you will have more code than you should but it is far from ideal. So I am thinking someone may know of something better to turn a lot of data "quickly" so long as I can avoid the OO for the fastest turnaround time for changes. Time is money...the real world
modified 7-Jul-17 21:24pm.
|
|
|
|
|
Joer4x4 wrote: Every time you pull data together to form a record you encapsulate the data.
No, data is aggregated by the db, before being consumed by the application. Read as an array of object usually. Does not require a class describing that set of data.
Joer4x4 wrote: Time is money...the real world
Been working there for a few years now, and most companies tend to value efficiency. I can also note that I would not be touching procedural code with a stick
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Interesting - It takes an application to create, use, and determine the structure of the data. The db is totally stupid until it is told what to do. The term here is used loosely as a db is a group of tables managed through specific software line DB/2, MySQL,or RMDBS. Even then you have to decide how you want the data stored (encapsulated).
An array is a group a similar data items. Records are a group of dissimilar data items. Last time I looked a class is an object. Classes are just different types of objects.
If you are a programmed you write procedures all the time so hold that stick. An OO method is just a fancy name for a procedure. A machine will always need instructions and it is procedural. All machines work that way because humandswork that way. It just life.
What was that about the experience thing...
Enjoy the day.
|
|
|
|
|
Joer4x4 wrote: An array is a group a similar data items. Records are a group of dissimilar data items. Last time I looked a class is an object. Classes are just different types of objects.
An array of pointers is not required to point to "similar stuff". And no, a class is not an object, it is a blueprint of an object. An object is an instance of a class.
Joer4x4 wrote: A machine will always need instructions and it is procedural
A machine will also need data, as procedures themselves are useless. OOP is about structuring and scoping both into logical reusable pieces.
Joer4x4 wrote: What was that about the experience thing...
Yes, you'll need more 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
"And no, a class is not an object, it is a blueprint of an object. An object is an instance of a class."
Stop... not true...
How many times I read a similar statement and chuckled? For in itself a class defines itself as a class, therefore and logically is has to be a object. It is an instance of itself. It has inheritance and can be inherited. They also tell you it doesn’t take up any computer space or storage. But if that were true, you could write a method without it. It’s in your code and classes are enforced. The compiler or interpreter may ignore it for creating machine code but is used for the human.
A blueprint is a real physical "object". Poor comparison but no other way to explain class. And why is that?
int x, y;
x = 0;
y = x;
So I created a class of x (int) and an instance of x. Is x not an object also?. X is inherently encapsulated unless we use a method (where x is the object of an imperative statement) to change it (x = 1). I can use it as a counter, an account number, product number, etc.. Counter, account number, and product number will not only inherent all x is, they are polymorphisms of x.
Where do you think OO concepts evolved - out of thin air?
"OOP is about structuring and scoping both into logical reusable pieces."
In that regard OO isn't any better than PL/1, COBOL, EDX, and a host of other non 00 languages.
|
|
|
|
|
Joer4x4 wrote: How many times I read a similar statement and chuckled? For in itself a class defines itself as a class, therefore and logically is has to be a object. It is an instance of itself.
A class is not an object, it is, as Edddy said, a blueprint from which an object can be created. If you really do not understand this basic concept of OOP you are likely to get yourself into some serious problems.
Joer4x4 wrote: A blueprint is a real physical "object".
Yes, it is a piece of paper with drawings of a physical object, but it is still only a drawing - a blueprint of a house is still not a house.
|
|
|
|
|
Joer4x4 wrote: Stop... not true...
That's the definition I gave the students
It is not a philosophy-class; instead of disproving the definition by using an incompatible real-world analogy, one is expected to use the definition to make sense of what the computer is doing.
I'd also point out then that OO is limited to programming-theory, and that the correct name would be OOP, since there is no OOI (Object Oriented Ironing).
Joer4x4 wrote: For in itself a class defines itself as a class, therefore and logically is has to be a object.
No. A class is not "logically" an object. An integer would also not be an object, but a value.
Joer4x4 wrote: In that regard OO isn't any better than PL/1, COBOL, EDX, and a host of other non 00 languages.
It is. Made it rather easier to re-use code, since one does not have to hunt all used global variables. Makes extending code a lot easier. Makes it easier to manage a larger code-base and dependencies.
There is a good reason that most code here is OOP-based, and not simply COBOL. Give it a try, you might actually like it
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: An integer would also not be an object, but a value.
In general that is specific to the programming language however. Smalltalk has no primitives - integers are objects.
|
|
|
|
|
I tried it 20 years ago. That's how I know I don't like it. Separate compilation of programs sharing the same data required more code than needed and you could not spread out the definitions with their logical modules that they belonged to. This is able to be done today but they had to break their own rules to allow it. For example your quote: "No, data is aggregated by the db, before being consumed by the application. Read as an array of object usually. Does not require a class describing that set of data."
Do you think I requested a non OO language out of thin air?
There is nothing to fear from a global variable. All variables are global after the compiler is done with it anyway. Imagine - all that work to hide them and its all thrown out the window anyway.
One rule that will never change is that the shortest line between two points is a straight line. I like living with that. It holds true for everything. To me OO curves the line by writing for the language.
Hey give one of the older languages a try. You might find the freedom of expression a breath of fresh air and the modularity and code reuse were already down to a science. Can you imagine pulling in an existing data structure with over (let's just say) 50 variables and redefining those on the fly with 1 line of code? How about a whole program? That's modular and reusable.
|
|
|
|
|
Since you seem to know so much more, and better, than everyone here, why don't you just get on and do it your way? Then you can showcase the results to prove us all wrong.
|
|
|
|
|
You do realise that most of the commenters here have experience in procedural, declarative, OO and functional programming languages don't you? Rather than dismissing them out of hand, you might want to reflect on their experience. Just because you tried something a little bit doesn't mean that you have a strong enough background in those areas to dismiss others; for instance, if your OO language of choice was C++, it was incredibly easy to write bad OO because you ended up writing it as a procedural implementation.
This space for rent
|
|
|
|
|
Joer4x4 wrote:
There is nothing to fear from a global variable. All variables are global after the compiler is done with it anyway. Imagine - all that work to hide them and its all thrown out the window anyway.
After compilation it is no longer required; I'll trust the computer to follow the instructions. Hiding the variables is not done for the computer, but for the programmer - to prevent spaghetti-code. Or worse, ravioli-code. So yes, scope only needs to be verified during compilation, not after.
I would consider the use of a global variable an offense that is equal to using a goto-statement.
Joer4x4 wrote: Do you think I requested a non OO language out of thin air?
No, of course not; you'll have better experiences/results with non-OOP code. That is a subjective view however, and general consensus points in the other direction.
There are multiple versions of BASIC, and two of the more popular ones are MSVB and VB.NET; where MSVB is usually VB4 or VB6. Both VB4 and VB6 are more procedural than OOP, whereas VB.NET is aimed at OOP but still supports the procedural way (a bit). When MS decided that VB7 should become OO there was a lot of wailing and gnashing of teeth.
Ten years later, you'll find that most of the VB6-crowd has made the move without much regrets.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
