Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Background
I recently joined a small start-up after working at a large company.
I'm not a professional system administrator, however, because of my programming and systems knowledge I am now the internal person managing our servers and infrastructure.
In the past, I never needed to document our system information: passwords (for servers, databases, routers, switches, etc), which servers were running which applications (both homemade and installed), server IP addresses, configuration file locations, etc...
The professional system admins always did this work, freeing me to focus on other areas.
Event that triggered urgency
I'd been a bit casual about moving this forward until I discovered that I didn't know where my main subversion configuration file was in /etc/apache2 (not to mention that the config file isn't under version control or backed up!) I realized that this needs to be addressed quickly.
Next step
I now have to figure out how to document all of this in a sane, elegant, access controlled manner.
I've heard of runbooks, but I don't know the best way or tools to manage them. My first thought was an excel/openoffice spreadsheet under version control.
Is there a good guide to maintaining runbooks? Good software? This must be a fairly common problem, how do you handle it?
I've actually had good success with a Wiki. Use something where you can control logins easily — Mediawiki is okay, but requires some PHP hacking — and build some templates for processes, inventories, and so forth.
Update
Actually, I must have needed coffee. Trac is pretty nearly ideal; better access control, integrated issue tracking, and a somewhat stronger text model. You can even tie it directly to your subversion repository so that you can hook actual scripts to their runbook pages.
Wikis are indeed a good approach. You can set up sharepoint for that and get nice features like update history, links that always point to current information and such.
If you use something like Puppet, (or Chef, or CFEngine, etc.) to build and manage your machines, then most of the runbook contents can live inside the puppet config, leaving you with a lot less stuff (just the location and password for the puppetmaster, if you take it to extremes!) to put in your wiki.
Related
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
I'm introducing a new Project-Management software in my company and looking into possible opensource software. Since i'm familiar with python, trac would be my first choice. but it looks like it is mostly used for software-projects, which isn't the case in my company.
Furthermore, time tracking is a big issue. We have multiple develeopers and each one should be able to track their time on the projects he worked on. This times schould be exported into csv at the end of each month (although i think i could to the export also directly from the DB)
So have anyone experiance with trac in non-software projects? It would be great to her some experiance from you, saves a lot of time for me ;)
We currently use Trac for our IT team. It allows us to track things such a help desk tickets, server projects and website changes. We have been doing this for over a year now and it is working great. It is even starting to spread out into other teams for managing team tasks!
As for pulling hours, etc from Trac, we use a custom field and then pull the data through the report module (now deprecated) and direct database access. In the past we have used plugins such as these.
http://trac-hacks.org/wiki/TimingAndEstimationPlugin
http://trac-hacks.org/wiki/TracHoursPlugin
We have also tied Trac into AD for authentication which allows for a single shared pasword for Trac and our domain.
For what it's worth I've setup a couple of Trac instances, that are totally unrelated to software development. Trac works well as a low entry barrier platform for any stuff I've encountered so far. We have all sorts of applications running, and especially the attitude to wikify anything is very nice - wiki markup in tickets, consistent link syntax across modules (changeset comments, tickets, wiki pages), etc. And I can confirm the viral effect, that a well-established Trac application has.
Trac it's very slim at initial setup, but feature-rice and modular from the ground to satisfy growing demand. For things like time-tracking you could use solutions like the TimingAndEstimationPlugin mentioned by Josh before as well. In general trac-hacks.org is a crowded space, not exactly easy to pick what you want, but a valuable resource anyway.
Make sure to ask at the trac-users mailing list and IRC channel #trac at irc.freenode.net, if you encounter some challenges. It's a small developer community, but a friendly one, and with some Python experience you'll surely find your way. Source code and wiki docs at trac.edgewall.org are always your friend.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
Is there a standard or de facto standard GUI administration panel for Redis? I'd like to see general health and status of my Redis instances through a web interface. Advanced stuff such as access to logs, trends on memory usage, etc. would be nice but not necessary. I'm running Redis on a Hadoop cluster, in which I enjoy having pages for the JobTracker, NameNode, Ganglia, etc.
There are a few out there, but at first glance they don't seem ready for prime time.
http://www.servicestack.net/mythz_blog/?p=381
http://code.google.com/p/redis-admin/
I am a big fan of Redis-Commander
Give a try to Redsmin (long description here). Its a fully online GUI for Redis that provides a lot of features.
It currently offers:
No installation and cross-platform
Multiple database management (with direct or proxied access)
Keys tree and list view (with optional real-time update)
Batch operation over multiple key that match a pattern
Data editor
LUA editor
Redis Cluster monitoring
Online configuration (with command override support)
JavaScript API directly accessible from the browser console for light data processing
Monitoring features
Online terminal with auto-completion and inline-documentation
Real-time data-visualization (histogram, pie, ...)
Monitoring (and alerting soon)
I've been running Redmon for a few days and it does a nice job graphing the live redis memory usage and keyspace, activity in a web UI with a CLI for typing redis commands too. It's a Ruby application which was very easy to run once the dependencies were installed.
redis-cli info provides a wealth of information about the health of a redis instance. Formatting its output for easier digestion shouldn't be too hard.
You can also try phpredmin. It provides simple statistics about your redis and a panel for manipulating databases and keys
I just found another redis admin program, single file, very easy to set up (I had to change the redis autoloader require on line 60 of the program). It's simple, but sufficient!
code.google.com/p/php-redis-browser
There is also the project RedWeb.
It is written in Python, and is built on the Bottle micro-framework.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm beginning a new project of about 1 year of development (for the first version) done with multiple developers, testers, etc.
I'm wondering if something exist that could help me do the following:
List all user goals
Associate functions to these user goals
Associate requirements to these functions
Associate design activities to these requirements
Associate development tasks to these requirements
Associate tests to these requirement
Qualify tests (system test, regression test, developer test, automated or not)
This way, I could:
Track if the program developed fulfill all user goals
Track if all functions are tested
Do a test matrix traceability to know if each requirements is tested
Track tests to do if a function is to be changed
Track the time needed to develop a function (it can serve later to estimate the time needed to modify it or to add a similar function to the program)
List all system tests to do when a new version is shipped
List all regression tests to do
List all developer test to do when there is a change in the function
List all automated test, this way we could know what is the percentage of the functions that are automatically testes.
etc.
You can suggest open source or commercial programs.
The Atlassian suite of software would seem to be a good fit and is very cheaply priced for a few users ($10 for up to ten users). I've direct (and good!) experience of using JIRA and find it very simple to use and flexible enough for my needs. Another alternative would be FogBugz, but I've no first-hand experience of using this.
re FogBugz, it is well worth having a look at the processes behind it, having worked on many non software projects I believe it is a universally sound methodology (even if Joel is a little quirky in his thinking.....).
I use SmartSheet because it is simple, but still has heirachial tasking, as you have set out in the question. It is good at dealing with people, unlikely it is good at manageing code, whereas FogBugz presumably does that.
A key feature of SS over Atl and others is additional users cost nothing.
One decision you have to make is do you want the project plan to be output in a simple way which many stakeholders can understand, or detailed so you can track much activity. Obviously the detail will require effort.
You have made a good start by setting out the issues, your culture of management may well be more valuable than the tool you choose.
ciao
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
I'm responsible of finding a good way to document the software project I'm working on.
What things are important to document? Should documentation of code and design mainly be in the code in the form of comments? Should we put text files or Word documents directly in the source control togetether with code? Should we use a wiki?
Factors to think about include how easy it is for the current team to create the documentation, and how easy it is for other developers to find, correct and extend the documentation later. My experience from many projects is that developers tend to not write documentation because the system for writing it is too complex or developer unfriendly, and that after a few years, new developers can hardly find the little documentation that was written.
I'm interested in what approaches you have used in similar projects. What worked well, what did not work well, and why?
Some key facts about the project:
The platform is C# and .NET.
We use Visual Studio and Team Foundation Server for source control and work item (task) management.
We use Scrum and test-driven development and are inspired by domain-driven design.
The software consists of a collection of web services and two GUI clients.
Other clients are going to integrate with the web services in the future. The integration will be done by other developers on other teams (so the web services form a kind of API).
SharePoint is heavily used throughout the development environment. Most projects have a SharePoint site, including ours.
On our project's SharePoint site we currently have a bunch of MS Office documents on things like requirements, design, presentations for stakeholders etc. Keeping everything up to date is hard.
We also have a SharePoint wiki for the development team only, where we document things in an unstructured manner as we go along. Examples include how our build scripts are organized, our testing policy, coding guidelines.
The software is an in-house application in a fairly big financial institution.
The software is developed by a team of six people over a period of ~1 year.
The developers are consultants hired in for this project only, and will not be available to help in the future (unless the client decides to pay for it).
The client has few guidlines for how this kind of project should be documented.
I think the most important things to document are the decisions. This goes for everything from requirements to architectural choices. What are the requirements of module X? How are these requirements represented in the architecture? Why did you choose architectural pattern A over B? What are the benefits? The same goes for source code: it is common knowledge that commenting the why is way better than the how.
How you document these decisions does not matter that much in my opinion, whether you use a Wiki or a Requirements document made in Word. More important is that these documents are always up-to-date and that it is easy for anyone to access them. This can be achieved by using a wiki, or placing the documents under source control, as you say. If only a few have access to them, they are more likely not to get updated, and not to be read when necessary.
We use a Wiki for our current project and it works very well. It is easy to access for anyone (developers, managers, and customers) and a history can track changes, so you know what has been changed and why. Furthermore, we try to document the code in a meaningful way and document the major design decisions. We try not to document too much, e.g. minor things, as it is always hard to keep those things up-to-date and it is not worth the effort, imho.
Worst for me than lack of documentation is excess of documentation.
Keep in mind that yes: it's really important to document your project, but also that the major part of your documentation is always at risk of never been read at all.
So, I think that a good starting point consist in thinking of your documentation more like something that you may use to introduce new developers to your project than an over detailed description of the inner workings of your software.
G'day,
Definitely use a wiki. I'd recommend TWiki as it's an excellent and extensive implementation of a wiki without being too complicated to install and manage.
Here's a couple of initial thoughts.
Categories:
Start off with an initial ontology of what you want to capture but
allow people to add new categories or sub-categories as required,
allow people to retitle (sub-)categories as required and maybe as agreed for this one so you don't get fragmentation for multiple names for basically the same thing.
let any initial (sub-)categories wither and die if they are left empty. Do this at the end of the project as some areas may only have entries towards the end of a project.
Tagging:
Start using a tag cloud. BTW here's an excellent plug-in available for TWiki to start classifying content early on in the project. Retrofitting tags is almost impossible to do. Starting tagging early also allows people to search for information that may be there already rather than having the same info located in multiple places.
HTH I'll come back and add more points as I think of them.
First and most important, have the comments written in such a way that NDoc can parse them. This is the best way to have the code itself documented, as the developers have to change their development practices very little, and you can generate pages that explain the code without having to look at the code.
Second, getting developers to write documentation is not easy, and getting them to do it might be an exercise in futility. This is where products like Fogbugz come into play. They will help manage the development with tickets, help track check ins, and when your done an iteration, generate release notes.
In conclusion, your best bet is to find the most effective solution that fits in with the devs existing process. If it impacts their development process very little, they will be more likely to adopt the system.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
For small-to-large teams developing software together, what tools are used to form a comprehensive team development framework?
Specifically, I'm looking for a comprehensive list of all the individual functions involved (e.g. source control, bug management, testing tools, project management), not specific product recommendations. I'm also not restricting the list to a particular methodology (e.g. Scrum).
Source control (obviously) including branch management
Issue tracking (features and bugs), possibly with task reassignment and forwarding, and often things like screen recording
Individual task management, sometimes integrated with the issue tracking system
Communication software. Some teams use emails and IMs even within the same building or tweets. There are some tools that integrated within the code so you could "chat around a piece of code". Screen and application sharing are also useful.
Good build tool.
Distributed pair programming tools if applicable, shared editors otherwise.
Similar support in case tools.
Less commonly used but promising tools (from academic background), some now have IDE based versions.
Real-time awareness (prevent nerge conflicts by letting you know somebody is working on the same file before you actually write code)
In-code social tagging, useful for bootmarking specific items
In-code contract communication tools (e.g., make a caller aware of special expectations in the invoked method as a way of avoiding errors).
You've hit the major ones in your post:
IDE (Integrated Development Environment)
Coding Guidelines (sometimes looked over, but it still helps tremendously)
Source Control
Testing Suite (Unit Testing, Test Case/Test Script Management and Tracking)
Issue Tracking/Bug Reporting
Build Management
...I'm sure I'm missing something obvious, but somebody around here will correct me.
And the one I missed...
Diagraming software (I.E. Rational Software Modeler, etc.)
A few more:
Requirements management software
Code review software
Continuous integration tool
Documentation repository - e.g. Wiki