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'm starting a new project that will be hosted on Windows Azure.
I'm using RavenDb as the backend and I would like to use CQRS and event sourcing.
I read good reviews of Jonathan's EventStore and it would fit perfectly into my architecture, as it is a thin layer and can use RavenDb as a store.
Now, I've noticed that the 3.0 release (latest official) is a year old and the new 3.1 hasn't been released yet (there is some activity in the branch).
I would like to go for the 3.1 version as it has CommonDomain project integrated, but I don't have any issues with referencing version 3.0 and current CommonDomain separatelly.
I am just wondering if the EventStore is actively developed and will be maintained, especially since Greg Young released his EventStore (geteventstore.com).
I am a bit reluctant to go for it, as it comes with it's own persistance and AFAIK I wouldn't be able to store my events in my RavenDb.
So to sum it up:
Is Jonathan's EventStore live?
If yes, should I go for the current official 3.0 release and reference CommonDomain project separatelly?
Is 3.1 branch (with CommonDomain merged) ready?
Should I switch to Greg Young's EventStore after all?
Or maybe should I investigate Lokad.CQRS? (I don't think it uses Jonathan's EventStore)
PS. I don't mind forking joliver's EventStore and contribute fixes / minor features.
I am using Joliver's EventStore in three systems currently in production and I intend to use it for more projects that will see production soon.
I think one of the reasons that there is less activity in the project compared to other projects out there is that it is very stable as it is. As far as I am concerned the code base is one of the best I have seen in terms of architecture and quality. Most of the activity now is plugins for different types of persistence.
The only thing I needed that wasn't in it when I got started was the possibility to upconvert events so I added that.
And to answer some of your questions.
I think it's live enough. I wont let it die anyway.
Go with the current release and the separate CommonDomain to allow for Nuget management of references.
No, I don't think it is.
Related
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.
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 9 years ago.
I am looking for what I could describe best as a collaborative software platform for our group (30+). We are currently using just a few svn repositories and it has grown unmanageable.
Our requirements are:
install-able on our own servers
revision control (should include svn not to scare the non tech people away)
issue tracking (bugs, tasks, etc.)
managing projects (users would be also nice)
mixed FOSS & closed source projects
From my research I found the following:
Launchpad (itself)
pro: about everything
con: no svn
FusionForge
pro: similar to SourceForge, has about all features
con: not sure how actively developed, should be quite cumbersome to manage
FusionForge
Gitorious (itself)
pro: also about everything on our list
con: only git, not sure about Ruby's security, intended only for FOSS
My biggest headache is that this platform should scale well also for not technically gifted developers while still keeping a minimum level of code quality.
Experiences with the 3 above or similar would be very appreciated.
Thank you
A couple that might fit your needs are:
Redmine
Trac
They are both has software project management features like:
Integrated defect tracking
Integrated wiki
Forum
Integration with wide range of version control software, including SVN
Flexible user authentication, mostly it relies on the web servers's authentication mechanism.
They are both open source and free. Redmine is developed using Ruby on Rails while Trac is using python.
Have a look at JIRA from Atlassian. It has a plugin for subversion. You can install it on your own server. It has excellent bug tracking facilities, you can define projects and define roles of users within the projects. You can use it with open and closed source projects. If one of your projects is open source you can apply for a free license.
If you want to build life around SVN as VCS-core, you have to see at UberSVN
More costly (extremely, compared to zero-price) solution, not limited by only Subversion, is Private Assembla
Have a Look at Gemini from Countersoft. It provides all the features you are looking for, either build in, or via free plugin (for SVN integration).
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.
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 using Fogbugz as my Bug tracking software, and was thinking on a schedule so that I can upgrade my Bug tracking software once in a while according to that schedule.
I was just curious on how others are doing their upgrades, and how often.
It would also be nice If you share on what basis you schedule the frequency of your Bug tracking software's upgradation.
Thanks.
I check for the changes implemented in any software and see if the new feature set and/or fixes provide benefit to our development team. In the case of FogBugz, I have not had a single problem caused by the upgrades. Fog Creek has done a remarkable job at testing their product before it hits our system.
I am not saying FogBugz is perfect, but it is close. I cannot say this about every software vendor. I really dislike when software installs screw up the workstations or the server. I use to be a jump on the new release as soon as it ships kinda guy. But too much blood loss being on the bleeding edge these days so I now wait a little bit and see who else has success or failure.
By the way, this is a business decision, not a technical decision. And I make it on a case-by-case basis depending on the reliability of the vendor and the level of importance the software makes to my company.
Rick Schummer
Whenever we need to. If running an older version still works, then thats what we'll do. If a new version has features that would aid development, then we'd upgrade after the next release of our product.
If we were to upgrade just because one became available, the response is usually that the bug tracking software is not as important as fixing the bugs themselves, and that it could wait.
There is no software free of bugs, even the bug tracking softwares.
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.
The FMDB page just offers the cvs checkout. Maybe someone out there wrote a good tutorial on how to use FMDB with sqlite3 on the iphone?
FWIW I have found CoreData to be buggy and unreliable, especially WRT its automatic model upgrading. I'm switching back to using raw SQLite and FMDB.
The source is the documentation, apparently.
The question, though, is why aren't you using Core Data?
Gus effectively compiled FMDB for the iPhone because Core Data wasn't available. Now that it is (as of 3.0), the need for FMDB is diminished.
Obviously -- if you need code portability, then the direct sqlite APIs are likely the way to go.
If you need data portability, then a wrapper like FMDB is probably the right answer.
If your portability is achieved through fully native apps with a client/server data flow architecture (which will offer the best per-device user experience, though at a potentially greater development cost), then Core Data is typically the best answer on iOS.
Check out this tutorial - I found it absolutely brilliant. Now using storyboards and ARC (automatic reference counting) myself, so had to modify the navigation parts a bit and skip the dealloc code, but if you are comfortable with xcode and sort of know what's going on, this is perfect. Nice explanations along the way, and no farting around:
http://www.youtube.com/watch?v=2Ojr7DZLghk&feature=channel&list=UL
I downloaded the latest FMDB files from their source - instead of using his. The latest files are updated for arc, and I had no issues. Get them here:
https://github.com/ccgus/fmdb
The xcode project in the svn repository has a fmdb.m file in it with plenty of usage examples to get you started.