Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
When you see games in BETA and ALPHA, lets use Minecraft as example, Minecraft when it was in ALPHA the title for the ALPHA versions for Minecraft where like "Minecraft APLHA C1.2.2_C1.2" for example. Not that it's really important but how do they get the numbers and letters (C1.2.2_C1.2 <- these numbers and letters) and what do they represent for is it numbers that are just kinda random? and how does a person go about to getting those numbers for there program? I normally just go ALPHA 1 - how many updates there is but I find it more professional to have titles like this "Minecraft APLHA C1.2.2_C1.2"? Thanks
A fairly uninformed answer is this:
Every development department of every software company in the world has their own versioning system, and the numbers and codes that follow a program name (when included at all) simply reflect whatever system happens to be in use. Different code repositories have different standards as well. It might be something like this:
myProgram-5.2.3.4
The 5 being first in the list, might mean this is the fifth major revision of this application. A major revision would be when the program has been fundamentally changed, like when a programming language that has never had OOP support suddenly caves in and provides it to their user base.
The 2, being second, would be a big change to the application that does not fundamentally alter it, maybe like a shoot'em up game implementing several new weapons that people had been begging for but didn't really change anything else about game play.
Successive digits indicate less important changes, with the last digit often representing bug-fixes - changes that are typically invisible to the end user but make the program more robust.
There are many other systems; it's up to you to decide which to use. I would do some searching on topics like "version control best practices" to learn more. Once you know what those numbers mean, you may find they tell you important details about an application you were unaware of.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
How long does it take to extend the functionality of a pos terminal?
I don't have any idea how long does it take to develop / extend functionality of a POS terminal. I have a friend who is asking me for this and we came across the "How Long Part".
My friend already has a running pos terminal that we developed with MQX Operating System by freescale (we are using K60 MCU) we bought it at aliexpress.
We were planning to extend the current source for NFC / contactless functionality (we also bought the reader from aliexpress)
Is developing it in 6 months time for 4 C++ developers sufficient enough?
To quote a classic:
[Y]ou’ve got to decide if you can deliver a Fortran compiler from scratch in seven days. You’ve got a staff of two programmers to help
you.
Can you do it?
“Well, I suppose, it depends,” you say.
On what?
“Um, will my team be able to use UML-generating tools?”
Does that really matter? Three programmers, seven days, Waterloo
Fortran IV. Are UML tools going to make or break it?
“I guess not.”
OK, so, what does it depend on?
“Will we have 19 inch monitors? And will we have access to all the
Jolt we can drink?”
Again, does this matter? Is caffeine going to determine whether you
can do it?
“I guess not. Oh, wait. You said I have a staff of two programmers?”
Right.
“Who are they?”
Does that matter?
“Sure! If the team doesn’t get along, we’ll never be able to work
together. And I know a few superstar programmers who could crank out a
Fortran compiler by themselves in one week, and lots of programmers
who couldn’t write the code to print the startup banner if they had
six months.”
Now we’re on to something!
If your team has worked together before, if you set your features to match your deadline (not the other way around), and if you have a keen sense when you've gone off the rails, probably. Presume you can, multiple your estimates by four, and carry on!
(Seriously, I can't answer this technically becuase it's a people question. But I hope it's inspirational! Good luck.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I always hear that we need to encapsulate whenever we write object-oriented code. If I'm the only developer on a project, do I still need to use encapsulation?
One way to put an answer: Encapsulation, conceptually, exists for writing better, safer, less error-prone code. It doesn't exist, primarily, to facilitate teams working together on code (that might be a side effect, but that's not the purpose).
So the goods that encapsulation seeks to foster scale from one coder to many coders, and they are goods that do not really have to do with the number of coders, although those goods may find stronger expression the larger the project and teams are.
Encapsulation is there for a reason.
Someone has to maintain and manage your code after you are done, right? What if the project gets bigger and you get team members?
So, the answer is "yes", it is always best to use encapsulation whenever possible.
The fact you are asking this question makes me wonder you actually did not get the actual value of encapsulation as a means to reduce and thus deal with complexity.
My theoretical computer science professor used to tell me that in the end, if you think at the whole binary representation of a program, any program is just a number. Very big indeed but, only a number. And that is true, any other construct we use but 0 and 1 (i.e. C++, Java, Python, functional programming, object oriented programming, aspect oriented programming, etc..) is just because of the fact we need more abstract means to get the one number we need.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So, I just started a new job a few weeks back. It is my first job doing software, and I have been tasked with learning how a giant project works. Now, the guy before me left NO (zilch) documentation or comments anywhere in the source code. In addition, he applied basically EVERY design pattern in the famous design patterns book by Gamma, etc...
My question is, how do I start? I have tried setting break points for certain calls that I want to learn (learn bit by bit), but because of the 5 million design patterns employed, every call goes up about 7 levels just to finish, and by then, it's hard to keep track of the 20 some objects being created and used.
Has anyone had a similar experience? A few pointers on different methods to try?
Specs: language - VB.net
IDE - Visual Studio 2010
Using - Windows Forms
Brain - Melting
Inheriting a large project without documentation is always a huge pain in the ass. I hope you have already accustomed your manager to the inconvenient truth that it will take several weeks or even months until you can maintain that project efficiently.
I would start with creating some UML class diagrams. That could tell you a lot about how the system works and which design patterns are used where.
While doing so, I would also add comments to the code with everything I learned about it. When I am not sure if I understood what the code does correctly, I would add a common string like "NOT_SURE" to the comment. Later, when I have a better understanding of the system, I could use a text search to find and revise these comments.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am trying to make a flowchart of my program (yes I know it is the wrong order to do it:) )
and I made a desicion symbol to represent the actionsheet I display in the iPhone application. It prompts the user "Yes, No, Cancel", so it is three options. However on all the templates/tutorials I have seen they only use "Yes" and "No" over the arrows which lead out from the desicion symbol. So could I use "Cancel" as well? If not how could I have done it otherwise?
You can do whatever you want with it, as long as it simplifies the meaning for your program. Decision making isn't restricted to 'yes' and 'no'.
Most of the time, flow charts are used to explain program logic to non-programmers. Your goal is to get them to understand what you program. We often use visual tools for this. You want to put all relevant information on there. If the cancel button is important to your program, put it on there. In my opinion there is no strict rule about what a flowchart should look like. Over time some basic form of flowchart has grown but you can add or remove whatever you want if it allows you to make more comprehensible charts.
Wikipedia suggests that decisions can have more than 2 choices, but should maybe be broken down. I see two options using a Google Docs drawing:
https://docs.google.com/drawings/d/11AhEIUOr9SdhXB1REculUy0NF9c628qaxfYVacUGfzU/edit?hl=en_US
I agree with the previous answer that the simpler it looks the better... whatever makes it most understandable. I think it's simpler to have 3 choices out of the 1 decision.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm working on quite complicated project, in terms of business-logic quantity and quantity of components.
Each developer mostly works on "his own" component. I understand that this isn't very cross-functional, but it is impossible to know every components' details.
Team sostav changes from time to time. So we have situations when one person have to work on "other person's component". And this can be on periodic basement, so you can come back to the issue a month later - in that moments you can ask component business-logic's owner the same questions again and again, because you simply can forget some tiny but important details a month later.
This situation is annoying sometimes.
We have daily stand-up meetings, when person tells about what he has done and going to do.
We have project's wiki F.A.Q. page - we extract the most frequently asked questions.
What do you think about the problem?
And how would you recommend us to solve it?
given the component nature I'd go with:
1.) A framework document specifying the applications purpose, setup, requirements etc.
2.) Module documents for each component in a common format and indexed by name.
Look at the http://docs.python.org for a good example of general docs and http://docs.python.org/modindex.html for a good example of module/component docs
Oh, and daily meetings are generally bad, they take up a lot of time and answers get forgotten. Newcomers or sick people miss the meetings and have to be re-briefed. It's 100x better to write it all down and keep a paper/email trail unless discussion/feedback is required.