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 have a legacy project written for Delphi 7. I'm about to integrate a bunch of new code into it which includes a test suite using DUnit. DUnit it not a part of Delphi 7 (it has been integrated later), so here's the question: should I include DUnit units into my project (check them into version control etc) or should I better require all the participating developers to maintain their separate DUnit installation?
The project is closed source and is written and deployed only within the enterprise I'm working for—that is, the project source code won't be delivered to any consumer.
The way you've worded your question, there may be some confusion as to what you're asking. So let's get that out of the way first.
It sounds like your asking whether to include DUnit units in your production application. This would be a very bad idea, and I'll avoid the details why in this answer.
However, I understood your question to be about whether you should treat this "third party" source like your own project source code (in terms of source control). And I've answered as such.
There are a number of principles that justify including DUnit source in your SC repository.
Whenever you have a new developer or new dev machine installation, you want to get up and running quickly, easily and with a minimum of fuss.
Only when all dependencies are managed within your source repository can the ideal be achieved. It's quite difficult to do better than: (1) Get Latest Source. (2) Build.
Even if you use a disk image with all required apps (including third-party libraries), it won't have 100% up-to-date source.
It is very important that all your developers are on the same version of DUnit.
Otherwise you risk having test cases that work on one machine, but might not even compile on another.
After you've made extensive use of DUnit, I'm sure you'll find various things (big and small) that you'll want to change. You'd best keep these changes in your repository.
My personal experience with DUnit is that parts of it are poorly designed. As a result some extensions are much more easily done by modifying the units directly.
I would even go a step further: Even though more recent versions of Delphi include DUnit, I'd still make a copy into Source Control. As much as DUnit is shipped with Delphi - it is really just third party source slapped into a folder.
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 7 years ago.
Improve this question
What is a good option for a continuous integration server for a small startup devshop?
We work in javascript technologies and make some hybrid apps, among other things.
I was looking into this issue, and came across Jenkins and TeamCity.
It seems like TeamCity is the way we'd prefer to go. I've read numerous blog posts about how TeamCity has a much smoother user experience and things just generally laid out with more clarity. With TeamCity we won't be going on too many a wild goose chase. But for the moment we're trying to skirt our expenses, too.
The free version of TeamCity comes with a server, and 3 build agents. The server delegates the tests to the agents. Is that enough for a small dev shop? I'm thinking probably, but what do I know. We need to test on two different platforms as well as web view (actually that considered maybe 5 platforms - chrome, firefox, safari, android, iOS).
What do you guys think, does a free TeamCity server have enough bandwidth to take on a small dev shop? We have 3-5 people working on a project at a time.
Please add any thoughts you may have about Jenkins vs TeamCity, too
Thanks
Managing your own build servers can end up being quite time consuming, and as such, expensive, even if the licence is free. You also need to remember that while the licence may be free, servers are not. I say this because if I were in your shoes, I would look into something like TravisCI or CodeShip.
It looks expensive compared to a free Teamcity licence, but you owe it to yourselves to atleast consider such an option. (There are others, those are two of the popular choices)
To answer the original question: I do believe that Teamcity will have the "bandwidth" to support your needs, but setup will take some time and effort.
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'm starting a new project, and I want to use Delphi for the desktop GUI. I'll be doing mainly typical client/server stuff with it (probably with Firebird). I have Delphi XE6 pro, and the older versions that came with it. And these are some of my somewhat flexible requirements:
The app should work on Linux and OSX, by running on top of Wine. (This was confusing, so I reworded it)
The app should work on Windows XP.
I'm thinking I'll use the open source VirtualTreeView and Turbopower GUI components. Or I may consider an older version of Devex that I have, that officially works with XE, but may (I don't know) unofficially work on a later version?
This project won't generate income right away, so I'd rather not buy a newer version of Devex (I'm currently waiting for some new work to start up, but there's no guarantee it actually will). Also, I read that XE6 will work with XP, even though it's not officially supported:
http://blog.marcocantu.com/blog/2014_april_xe6avaialble.html
But I'm still not comfortable with the idea, since Embarcadero didn't actually test it. And 3rd party support could also be a problem.
What your question boils down to is whether or not the latest versions create executables that run on XP, and then on your targeted Wine versions.
Mostly that depends on what functions you call. If you call functions that aren't present in XP, then your program won't run on XP.
A plain vanilla VCL app from XE7 will run on XP. It's what you do then that counts. Simply, you'll have to take care, and test plenty.
My large app still runs on XP and is built with XE7. So it's perfectly possible. As Marco said in his comment, Embarcadero are not yet actively changing the VCL so that it breaks on XP. But they no longer test on XP.
Personally I'd sooner use the later versions so that I had access to generics. I know XE had generics, but the implementation was still a little buggy.
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
We are building a very large enterprise web application using Visual Studio 2013 ASP.net MVC 5.
We are using TFS 2013.
We create one team project in the TFS.
Now in visual studio, we need best practice or guidelines to structure our application that contains about 14 modules.
1) create one really large solution containing all projects for all modules of the application.
2) create many smaller solutions with fewer projects in each.
Thank you.
Your choice will depend on one factor:
A. Does the team(s) involved in the project need to maintain every project of your solution?
One solution to rule them all, because otherwise your team mates would need to recompile parts of your entire project in different Visual Studio instances, and this can decrease productivity of your team, and it can lead to errors since more than a team mate will miss to recompile something and he/she'll get into big troubles until someone would tell him/her: just recompile X solution to get this working (or it can take to a documentation nightmare...).
B. Does each part of the project gets developed by many specialized teams?
Many solutions for the same main solution. Imagine that front-end team needs to consume infrastructure and domain code, and they aren't allowed to edit that last code base. Thus, front-end team would be able to edit front-end code base, and the backend team the rest of it.
Anyway, this implies that you'll need to configure TFS continous integration with TFBuild in order to drop latest and fresh backend built code in some network share, so front-end code will be able to binarily-reference these assemblies.
In other words: if there's a framework team and application team, maybe this approach makes sense. Otherwise, it'll be better to go with the first approach.
Side-note
Anyway, a solution composed by 30 projects it's not a big solution! I wouldn't pay too much attention to this, and I would go with A. approach...
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
As ,AFAIK, there is no way to compile Objective-C on a Windows machine. Would it be reasonably easy to set up a Mac server that compiles everything for you.
I am writing a game making system and it generates Objective-C code for you and creates an XCode project file. I was just wondering if I could give users the ability to compile there projects through server.
Could I setup a server that compiles XCode reasonably easily or are there services already available which I can direct users to that already do this?
I am aware of DragonFireSDK but that is for DragonFireSDK and not for third-party software, ASFAIK. I would think that they would try to make you buy DragonFireSDK to use there server for compilation.
Please note that I do not expect to find any servers where they compile Objective-C for you but I am hoping there are paid services that do this for you.
Please not I have literally just about no knowledge or experience of servers and/or server programming.
Thanks
Recently, I was looking to do the same thing. I develop for jailbroken devices. In our community, lots of people that can't afford Macs use Linux for building their projects. I see it quite a bit.
Clang/LLVM and Apple's ld64 are used to compile and link Objective-C projects. Luckily, all three are open source, meaning that you can use them on just about any UNIX-based OS. (I think Clang/LLVM supports Windows too, but I doubt ld64 does)
There are many toolchains people have put together to build iOS projects on non-Mac operating systems. You can Google them.
Darling
My personal favorite is the Darling project. It is similar to Wine in that it allows you to run Mac OS X binaries on Linux. When used in conjunction with Apple's toolchain that comes with Xcode, it works wonderfully, much better than any other toolchain. Also, since Apple has yet to commit arm64 support to Clang/LLVM (it's still closed source), this method still allows you to compile for arm64. It's also pretty reliable, in that you'll be able to update your toolchain the second Apple releases a new version, without having to wait for the source code.
I use Darling in my server for copy protection. When someone purchases my product, my server builds a copy specifically for them, embedding their device information in it. That way, if it is pirated, I can see "who dun it". It currently builds 5-6 copies a minute when sales are high, and so far, it has handled the strain just fine.
I've written a (somewhat long) tutorial for setting up Darling on Linux. It's targeted toward jailbroken development, but I'm sure you can adapt it to suit your needs.
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
Ok, this sounds like a bit of a rant, but I was wondering if there was a technical reason that Erlang doesn't have a proper package management system by default.
No major technical reason really. Just different needs as the classic way of setting up and installing erlang software is though applications. And some use releases added to that.
Often you see erlang software distributed completely self reliant. That is that it contains all the libraries and the virtual machine together in a package and not needing any sorts of external dependencies. You even see this in development versions of packages. The source tree of the Riak database for example has all dependent libraries in it.
This is not a bad idea like many coming from Ruby(like me) may think. This way each application is self reliant. As one of Erlang's main goals is to be the most reliable thing available it makes every sense in the world that each application can have it's own version of the library. Thus making sure one app does not make the other unstable.
Try rebar; it's a build system for erlang that includes a dependency management system. It doesn't have a central repository like gem does with rubygems.org, so you have to specify git urls. But, it does save you the trouble of having to download nested deps; it takes care of that itself.
And it sticks with Erlang's philosophy by keeping the downloaded deps inside your project directory rather then in a central system location; this is similar to bundler's deploy mode.