I'm searching for the opportunity to use the existing wiki in Redmine project independent.
Why project independent?
I need it for general topics and plugins which are not part from a project.
Or exists a plugin which I can use for this?
People generally create a "General" project or something similar for the global stuff.
Everything in Redmine is part of a project. There are no global areas with user-acccessible data. This is by design, is leveraged by the permissions system and other areas and is not about to change.
Related
I'm a seasoned C++ developer in a new position. My experience is in *nix-based systems, and I'm working with Visual Studio for my first time.
I find that I'm constantly struggling with Visual Studio for things I consider trivial. I feel like I haven't grokked how I'm supposed to be using VS; so I try doing things "the way I'm used to," which takes me down a rabbit-hole of awkward workarounds, wasted time, and constant frustration. I don't need a VS 101 tutorial; what I need is some kind of conversion guide - "Here's the VS way of doing things."
That's my general question - "What's the VS way of doing things?". That might be a bit vague, so I'll describe what's giving me grief. Ideally, I'm not looking for "Here's the specific set of steps to do that specific thing," but rather "You're looking at it wrong; here's the terms and concepts you need to understand to use VS effectively."
In C++, I'm used to having a great measure of control over code organization and the build process. I feel like VS is working strongly against me here:
I strongly tend to write small, isolated building blocks, and then bigger chunks that put those blocks together in different combination.
As a trivial example, for a given unit or project, I make a point of having strong separation between the unit's headers meant for client inclusion; the unit's actual implementation; and any testing code.
I'm likely to have multiple different test projects, some of which will probably rely on common testing code (beyond the code-under-test itself).
VS makes it onerous to actually control code location. If I want a project's code to be divided into an include/ folder and a src/ folder, that's now a serious hassle.
VS's concept of "projects" seems, as far as I can tell, somewhere between what I'd think of as "final build target" and "intermediate build target." As far as I can tell, basically anything I want to share between multiple projects, must also be a project.
But if many intermediate objects now become projects, then I'm suddenly finding myself with a TON of small projects.
And managing a ton of small projects is incredibly frustrating. They each have a million settings and definitions (under multiple configurations and platforms...) that are a real pain to transfer from one project to the other.
This encourages me to lump lots of unrelated code together in a single project, just to reduce the number of projects I need to manage.
I'm struggling with this constantly. I can find solutions to any one given thing, but it's clear to me that I'm missing a wider understanding of how Visual Studio, as a tool, is meant to be used. Call it correct workflow, or correct project organization - any solutions or advice would be a real help to me.
(Note: much as I'd like to, "Stop working with the Visual Studio buildchain" is not an option at the moment.)
The basic rule is: A project results in a single output file [1].
If you want to package building blocks into static libraries, create a project for each one.
Unit test are separate from the code, so it's common to see a "foo" and a "foo test" project side by side.
With respect to your small building blocks, I use this guideline: If it is closely enough related to be put in the same folder, it is closely enough related to be put in the same project.
And managing a ton of small projects is incredibly frustrating. They each have a million settings and definitions (under multiple configurations and platforms...) that are a real pain to transfer from one project to the other.
Property pages are intended to solve this problem. Just define a property page containing related settings and definitions, and it becomes as easy as adding the property page to a new project.
As each project can pull its settings from multiple property pages, you can group them into logical groups. As an example: a "unit test" property page with all settings related to your unit test framework.
To create property page in Visual Studio 2015: in the View menu, there is an option "Property Manager". You get a different tree view of your solution, with the projects, then the configurations, and then all the property pages for that project+configuration combination. The context menu for the configuration has an option to create a new property page or to add an existing one.
[1] Although it is common to have the Release configuration result in foo.dll and Debug configuration in food.dll, so they can exist next to each other without resorting to the Debug/ and Release/ folders. In the General properties, set the TargetName to "$(ProjectName)d" (for Debug configuration) and remove the "$(Configuration)" from the OutputDirectory (for all configurations) to achieve this.
What is the best app for row level permissions in Django?
There are many of them at http://djangopackages.com/grids/g/perms/, but how to choose more promising one?
You can try the following that is suitable for any kind of project:
Project popularity between devs: Check the number of contributors. In GitHub or BitBucket you can get the number of followers/watchers, forks and clones.
Documentation matters: Avoid the "read the code" dilemma, check if the project is well documented and the compatibility with other packages (like Django).
Maintenance of the project: Check if there is issues with "open" status for a long time and without response.
Evaluate the open issues of the project: If the project have open issues, take a look if some of this issues isn't a big problem for your needs.
Check the plugability: Depending on your needs you may choose a project that is more easily plugable than others.
What I can say more is that I've already used django-guardian and it fitted my needs at the time. I think it fits in almost all of these considerations above but give others a try too.
I've jumped into a project that uses dotCMS. The problem is that there is only one book about this cms (which is pretty incomplete as far as I concern) and..even their official documentation is incomplete as well.
as far as I now, dotCMS is opensource, but I can't find any .java files.
Anyone knows if I can add/remove core functionalities of dotCMS?
I'm trying to add a new field to categories.
Sure you can. The dotCMS plugin architecture can provide 90% of most functionality you would be looking to add and have the added benifit of not breaking your upgrade path. If you want to modify the source (and the core), you also have access to the community code here:
See:
http://dotcms.com/community/svn-access.dot
for instructions on how to download the source files and see:
http://dotcms.com/docs/1.9/Installation#InstallingFromSVN
on how to get it running from source.
I've been checking out Faxien+Sinan and Rebar, and the basic philosophy of Erlang OTP seems to be, install applications and releases on a single Erlang image instance. What are the best practices for keeping releases self contained? Is there a way to package releases such that you don't have to modify the site for machines that you're deploying to? How about gathering all dependencies into the codebase for management?
Perhaps I'm going against the grain... I come from a Java background and the philosophy of "nothing pre-installed but the JVM" seems very different.
IMHO this can't be answered in a few sentences. You should have to read some parts of the included documentation, especially "Erlang/OTP System Documentation" (otp-system-documentation-X.Y.Z.pdf, with X.Y.Z being the version number), or have a look at the book "Erlang and OTP in Action" because throughout this book there is "one" example of a "service" with different "parts" from the first steps, using Erlang/OTP concepts and finally building a "release".
IMHO this is currently the best book around, because it not only introduces Erlang, but also shows what OTP is and how OTP is used for a project. And it is not just a collection of loose samples, but everything is build around a single project.
I'll describe the approach that currently works for me for regular (often daily) releases to a small number of instances on EC2:
I set up my project with rebar and check it into github.
All of my dependencies are listed in my rebar.config file (they too are on github).
My Makefile looks similar to what I described here.
My EC2 image only has a regular build of erlang and no other libs installed by default.
To create a new node, I spin up an instance, clone my git repository, and run make. This will fetch my dependencies and build everything.
To update my code I do a git pull and a rebar update-deps. Depending on what changed I may restart the node or, quite often, I'll attach to the running node and reload the updated modules. It helps to have start and attach scripts as part of your project.
It may be helpful to look at how a project like webmachine is packaged.
I don't know much about the standard OTP release management system, other than it looks like a lot of work. Because this seems counter to rapid deployment, I never gave it a serious try - though I'm certain it makes sense for other projects.
Can anyone list the steps needed to programatically install an application on Windows. Aside from copying the files where they need to be, what are the additional steps needed so that your app will be a first-class citizen in Windows (i.e. show up in the programs list, uninstall list...etc.)
I tried to google this, but had no luck.
BTW: This is for an unmanaged c++ application (developed in Qt), so I'd rather not involve the .net framework if I don't have to.
I highly recommend NSIS. Open Source, very active development, and it's hard to match/beat its extensibility.
To add your program to the Add/Remove Programs (or Programs and Features) list, add the following reg keys:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\PROGRAM_NAME]
"DisplayName"="PROGRAM_NAME"
"Publisher"="COMPANY_NAME"
"UninstallString"="PATH_TO_UNINSTALL_PROGRAM"
"DisplayIcon"="PATH_TO_ICON_FILE"
"DisplayVersion"="VERSION"
"InstallLocation"="PATH_TO_INSTALLATION_LOCATION"
I think the theme to the answers you'll see here is that you should use an installation program and that you should not write the installer yourself. Use one of the many installer-makers, such as Inno Setup, InstallSheild, or anything else someone recommends.
If you try to write the installer yourself, you'll probably do it wrong. This isn't a slight against you personally. It's just that there are a lot of little details that an installer should consider, and a lot of things that can go wrong, and if you want to write the installer yourself, you're just going to have to get all those things right. That means lots of research and lots of testing on your part. Save yourself the trouble.
Besides copying files, installation tasks vary quite a bit depending on what your program needs. Maybe you need to put an icon on the Start menu; an installer tool should have a way to make that happen very easily, automatically filling in the install location that the customer chose earlier in the installation, and maybe even choosing the right local language for the shortcut's label.
You might need to create registry entries, such as for file associations or licensing. Your installer tool should already have an easy way to specify what keys and values to create or modify.
You might need to register a COM server. That's a common enough action that your installer tool probably has a way of specifying that as part of the post-file-copy operation.
If there are some actions that your chosen installer tool doesn't already provide for, the tool will probably offer a way to add custom actions, perhaps through a scripting language, or perhaps through linking external code from a DLL you would write that gets included with your installer. Custom actions might include downloading an update from a specific Web site, sending e-mail, or taking an inventory of what other products from your company are already installed.
A couple of final things that an installer tool should provide are ways to apply upgrades to an existing installation, and a way to uninstall the program, undoing all those installation tasks (deleting files, restoring backups, unregistering COM servers, etc.).
I've used Inno Setup to package my software for C++. It's very simple compared to heavy duty solutions such at InstallShield. Everything can be contained in a single setup.exe without creating all these crazy batch scripts and so on.
Check it out here: http://www.jrsoftware.org/isinfo.php
It sounds like you need to check out the Windows Installer system. If you need the nitty-gritty, see the official documentation. For news, read the installer team's blog. Finally, since you're a programmer, you probably want to build the installer as a programmer would. WiX 3.0 is my tool of choice - open source code, from Microsoft to boot. Start with this tutorial on WiX. It's good.
The GUI for innosetup (highly recommended) is Istool
You can also use the MSI installer built into Visual Studio, it's a steeper learning curve (ie is a pain) but is useful if you are installing software in a corporate environment.
To have your program show up in the Start program menu,
You would need to create folder
C:\Documents and Settings\All Users\Start Menu\Programs
and added a short cut to the program you want to launch.
(If you want your application be listed
directly in the Start menu, or in the programs submenu,
you would put your short cut in the respective directory)
To programically create a short cut you can use IShellLink
(See MSDN article).
Since you want to uninstall, that gets a lot more involved because you don't want to simply go deleting DLLs or other common files without checking dependencies.
I would recommend using a setup/installation generator, especially nowadays with Vista being so persnickety, it is getting rather complicated to roll your own installation
if you need anything more than a single executable and a start menu shortcut.
I have been using Paquet Builder setup generator for several years now.
(The registered version includes uninstall).
You've already got the main steps. One you left out is to install on the Start Menu and provide an option to create a desktop and/or quick launch icon.
I would encourage you to look into using a setup program, as suggested by Jeremy.