Practice / Example codes in the repository [closed] - version-control

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Suppose that I host a project in some open source project hosting services like Google Code, Git hub or Sourceforge, is it a good practice to place the examples / practice code in the repository which I used to learn the technology? For eg., while developing an application I might develop some samples to learn JUnit or Regex and so on. Can I place them in the repository as well? Will it confuse the visitors of my repository?

You should only version what you need to develop/run the project.
Any other set of files could be in its own repository (as a submodule for instance for git), and referenced from the main project if you want.
That way, you still see those file on your main project checkout (if you include submodules), but you can also get your main project without any of those extra files.

You should not put sample spikes into the main repository of a project. You could negatively impact the build process for the project (or even the code itself). My last project has ~50 sub projects/teams and took close to 24 hours to build the whole thing from scratch; it was a monster. Adding everyone's sample code would have made this build even worse. It should be considered a bad practice.
The previous answer about creating a submodule would be a better way to handle this.

I wouldn't put testing samples in the same repository as your actual project.
But IMO there's nothing wrong with publishing them in an own repository.
I like testing samples made by other people. If it's a new topic for me, I find that I can understand a test sample by someone else who is learning as well better than a full-fledged project by someone who is already familar with the topic.

Related

Shared assembly versioning and issue tracking [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We have 3 teams developing 3 different projects(.NET), and there is one project with common code and controls SharedLibrary. Each team references it using sub-repository in Mercurial.
Each team is allowed to push changes to SharedLibrary to fix bugs in their projects. So there is a possibility that fixing a bug in one project may introduce a bug in the second one.
We're using JIRA for issue tracking, and there are 4 projects (for each team and for SharedLibrary).
So, could anyone suggest a workflow, which reduces chances of integration failure(one team breaks other team project) and in case failure happened helps to reveal it as soon as possible?
Points to consider:
Do we need a version for SharedLibrary in JIRA? How it should be maintained?
Who and when verifies changes made to SharedLibrary?
What is the best way to organize branches in hg?
What is the best way to organize JIRA workflow? In what project in JIRA are the ShareLibrary issues filed?
Any help or examples of workflows/solutions for the similar situations are highly appreciated.
Couple of suggestions:
Yes, you should maintain versions for SharedLibrary just like you do your other projects. You should tie the release of each of your 3 projects to a specific version of SharedLibrary. If you just let any of the 3 project teams change it without referring to the other teams, you'll have a high risk of introducing non-compatible changes.
If SharedLibrary isn't maintained by a specific person or team, I'd suggest having a cross functional team made up of representatives from each project team that is responsible for reviewing updates to SharedLibrary. They can use JIRA to track the issues by version. To verify that changes don't break other projects, have a comprehensive set of tests for each project that you can run in a continuous integration server such as Jenkins.
I don't have any particular suggestions here.
I would keep SharedLibrary as a separate JIRA project.

Alfresco or Liferay, which is better for WCM? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am exploring CMS tools Alfresco and Liferay, but cant decide which is better for Web Content Management.
Please help me decide which tool to use for web. Opinions and suggestions are welcome.
Just use your favourite search machine and voila I've got topics covering this question:
e.g. here
If you can't decide, go for the pragmatic solution and just pick one.
You'll have to decide if you rather like the Content- or the Portal-centric approach - e.g. what else other than CMS do you expect from the solution you choose. As you ask for opinions: I'm tending to prefer a portal (but then, I'll have to disclaim that I work for Liferay) because it can integrate quite a lot more functionality - and extension is done through a well known standard interface (portlets). And I'm typically seeing requirements that ask for more than just content management.
Integration of both products is possible, but it's an additional effort that needs to be done - and you'll have to understand both. There are many people doing that, but if one solution goes 95% of what you need, you could save yourself the integration work.
But if you really want some useful answers here you might want to give more information about what you actually want to use them for, because personal opinions and suggestions might not help you with your personal requirements if you leave them unknown.
This blog post should be helpful enough as to WCM in Liferay. Talking about WCM (not Document/Enterprise content management) I would go with Liferay, because it is really easy and quite powerful, especially recently after a few new features were introduced (very cool web content staging and versioning). Alfresco is good for enterprise content management, but I wouldn't choose it for WCM, the Spring Surf and Spring Web Scripts it is using was quite hard to get used to.

Need good source control [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I am working on my C programming skills. I decided to run Ubunutu Linux and use code::blocks as my IDE. Now, I need a good source control.
Something that's easy for a beginner to administer (I want to concentrate on coding not managing a server)
Free
Hopefully has a plugin that integrates well with code::blocks
I plan to use source control for my own use. I want to be able to undo my changes if I make too many mistakes. I also want to be able to revert back to an old version and do side-by-side comparisons.
Maybe one day, my buddy and I could work on some code together (from different locations), but this is not a major concern at this time.
What works for me?
You want Mercurial or Git. I personally prefer Mercurial.
Subversion is still very popular and stable. It's centralized though, which these days is considered "the old way." (I've heard people say "Git is to SVN what BitTorrent is to FTP.")
Git is pretty much the in thing right now. In my opinion it has a higher learning curve, but its adoption by the open-source community is widespread.
Mercurial is a great DVCS and, in my opinion, doesn't get enough attention. Great commercial products are built on top of it, though, so growing your project to a commercial system is pretty smooth.
There are others.

How to add a new feature to an existing component? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
We have this legacy image viewer component in our project that's working fine but it's source is a real mess. I have to add a new feature to this component so that people can add annotation to images using a light pen which is not a complicated task per se but could be a nightmare dealing with our existing code.
I'm really confused right now I don't know where should I start . do I have to refactor the existing code?if not what else can I do?
So here's my question: What could be the best (less painful) approach dealing with such situations?
The question is not an exact duplicate, but this exact same answer applies (you just have a list of one change)
https://stackoverflow.com/questions/1386824/hired-as-a-developer-to-maintain-and-update-current-code-base-no-docs/1386844#1386844
Write lots and lots of tests that will allow you to verify that changes you make to the system do not change or break existing functionality.
These tests are like the brace-work that is used to support a physical building when a construction crew is doing reconstruction. That brace-work is used to keep the existing infrastructure intact. You need to preserve the infrastructure of your system with as many unit and integration tests as you have time to write.
These tests will allow you to make small, iterative changes to the system and easily verify that those changes still maintain the expected behavior.
You should read this very good article Big Ball of Mud. And for your answer we all get a big ball of mud at some point and we need to add new functionality to it. Re-factoring such a code is not a good idea since it require alot of testing. But adding few new lines will not harm it. So unless you have alot of time and so does the tester just add the new functionality to your existing code. Although the current code look messed up but remember it works and tested. Read the article and makeup your mind as to which approach is good.

IDEA Community Edition versus Eclipse [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
How does the IDEA Community Edition compare with Eclipse?
IDEA is a far better IDE than Eclipse (general opinion by people that use IDEA).
On a feature point of view, everything that IDEA CE can also been done by Eclipse. However,
IDEA is a commercial product, which limits its adoption. Thanks to the Community Edition, you can test this IDE for free, in order to develop JavaSE applications (or Scala or Groovy). For an enterprise, this is quite limited, as you will not be able to develop J2EE applications.
My conclusion is that IDEA CE is only a tool that allows you to test and understand the philosophy of this IDE. If you are convinced by IDEA, then you will really have to choose between the Ultimate Edition, which will let develop any kind of applications, or stay with Eclipse.
The best, straight answer to this, is to look at the feature matrix of which features are still left in Ultimate-Edition. Eclipse probably has support for all of these things, although the quality of the integrations can always be an issue.
Why IDEA:
detects unused public fields and methods
easy way to run or debug only one test method (you don't need to modify configuration)
faster code coverage report generation (at least for EMMA)
understand difference between source and test source
easier way to manage libs - just include lib dir (in eclipse you have to specify all jars explicitly), so you don't have to update it manually every time when new jar was included