Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
Are the any task tracking systems with command-line interface?
Here is a list of features I'm interested in:
Simple task template
Something like plain-text file with property:type pairs, for example:
description:string
some-property:integer required
command line interface
for example:
// Creates task
<task tracker>.exe -create {description: "Foo", some-property: 1}
// Search for tasks with description field starting from F
<task tracker>.exe -find { description: "F*" }
XCopy deployment
It should not require to install heavy DBMS
Multiple users support
So it's not just a to-do list for a single person
Ditz is a simple, light-weight distributed issue tracker designed to work
with distributed version control systems like darcs and git.
Ditz: http://web.archive.org/web/20121212202849/http://gitorious.org/ditz
Also cloned here: https://github.com/jashmenn/ditz
Interesting idea; the closest thing I have heard of is todo.txt.
Alternatively, you could roll your own by just using a database (e.g. sqllite) and SQL. Optionally, write a wrapper script that parses your plain-text file and command-line options, and generates the corresponding SQL.
Have you seen ticgit. It sounds like it might do just what you guys are after.
Erlangs Ticket System
Created by Peter Högfeldt in 1986. This is the ticket system that was used in the Erlang distribution.
Source: Joe Armstrong's blog
http://roundup.sourceforge.net/
#Peter Hilton,
I'm going to create such system. So I'm wondering whether such system exists. General idea is to keep it as simple as possible: command line utility to manage tasks & simple server wit REST interface. I used dozen different task tracking system and come to conclusion that I don't need fancy UI. It should be like Subversion - you can happily work with command-line based svn.exe
I've abused the cal and calendar commandline tools regularly for this type of task.
ciss issue tracker is a simple commandline tool for managing your ISSUES.txt file.
Fogbugz has a Command Line Client.
Have a look at Pitz and Bugs Everywhere.
I use org-mode with emacs in terminal mode (emacs -nw).
We have used a few tools earlier. We now use a GitHub private repository to maintain various developer TBD lists (as .md files) and issue tracking because of the following advantages:
Developers are already using GitHub and they don't need to learn anything new.
Developers can use whatever tool they are comfortable with to maintain TBD list; command line or graphical editors, GitHub web interface or plenty of mobile clients
Markdown support
Reliable backup
Merging and revision history
Flexible file organization for different projects and modules
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 6 years ago.
Improve this question
I have heard from my peers on more than one occasion that it is "advised" not to do version controlling of your code from within the IDE where you write it. I have seen them developing on Eclipse, IntelliJ IDEA, etc. but doing version control (in my current scenario - Git) from command-line or standalone clients as opposed to using the corresponding plugins readily available for the IDE.
Though I have used version control plugins in Eclipse and never found any issues, I would like to know what is the general norm and why?
I don't think that there's a general norm. The answer to the question is highly subjective.
I personally don't use any IDE integration (not even a GUI tool, except the builtin ones git gui and gitk) because my experience told me that these tools behave different than the command line version and/or don't provide the full functionality available on the command line:
Does NetBeans ignore my Git pre-commit hook?
Can you interact with the index/staging area with TortoiseGit?
Does TortoiseGit actually make Git a lot easier to use like TortoiseSVN?
Another thing is that your knowledge about your versioning tools is bound to your IDE. Maybe you want to set up some version management for other things than the sources you edit with Eclipse (your dotfiles, for example).
Or one day you switch your IDE, drop Eclipse and start using Visual Studio. Then you don't have to learn only Visual Studio but in addition you need to learn the Git integration in VS too.
I think compared with what I've written above, there are no serious advantages that would legitimate the usage of version control tools from inside the IDE.
So, IMO, it's a bad practice to do version control from inside the IDE and it should always be done from the outside.
You should always try to use the right tool for the job, and that is a personal question so there is no "norm" or "good practice".
In my case I prefer to use a ...
GUI, like Sourcetree, for viewing logs, diffs, staging/discarding lots of files, staging/discarding hunks, etc.
CLI for modifying remotes, squashing commits, pushing, cloning, etc.
Also, if you plan to break out of the box a little bit, it wouldn't hurt to know a little bit about the Git internals.
Those plugins and add-ones tend to sometime do things that otherwise you wouldn't do if you were using the native (CLI?) client.
For example, if you were working with an Eclipse + ClearCase plugin, any change in a file, even adding a new line, will initiate a check-out operation (depending on the configuration).
Specifically for Git, you should be aware of its internals to properly work with it. Using the IDE hides those things from you. In normal trivial operations, it will work. But, when you are facing a source control issue (ugly merge, cherry-picking, rebase conflicts) you will have to go to the CLI to resolve, but then you have no idea what were the actual commands that the IDE ran that got you to this situation in the first place (plus you have no experience with the CLI at that point).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
My internet connection is extremely slow and therefore I execute batch files on the server without GUI, i.e. directly from the terminal. However, oftentimes I need to make a few changes in the code and a text editor highlighting Stata syntax would not hurt. Is there one?
Sublime Text editor has a package for Stata. If you're using mac you can find installation instructions here.
As linked by Maarten Buis, Nick Cox's list is the reference. It's a cool list, but it's badly outdated and therefore misses out the best parts of Stata support on Mac OS X. Here are some additions that also allude to the other answers.
Mac
TextMate has two Stata bundles, the Beatty bundle and the more recent Schumm bundle that uses a smarter approach to Stata syntax. (Note: not sure whether the Beatty bundle works under Stata 13; the Schumm bundle, which is the one you get through TextMate's bundle settings, does.)
Two other editors, Chocolat and Sublime Text, support TextMate bundles or ports of TextMate bundles. Phil Schumm's Stata bundle for TextMate is the most advanced and up-to-date solution that I know of, so I'd recommend that if you need an external editor.
TextWrangler also supports Stata through its own plugin system. I guess that BBEdit might therefore support it too, probably through slightly more awkward AppleScript calls. The only reason I see to use these instead of TextMate is if you are running an old system and/or are using these editors already.
If you need more alternatives, check out websites like Alternative To, I Use This, MacUpdate or VersionTracker for a larger choice of options. You'll find out that SubEthaEdit and Smultron (and probably its deceased fork, Fraise) support Stata, for instance.
tl;dr On Mac OS X, use TextMate with the Schumm bundle, and you will like it. (No idea if you can create GitHub issues through email, though!)
Win
Notepad++ has support, and there are mentions on Statalist of PFE, UltraEdit and WinEdt also having support. My guess is that you will find it more useful to get Sublime Text and use its Stata bundle port, unless again you are already using these editors.
tl;dr On both Mac OS X and Windows, Sublime Text with the Stata TextMate bundle port seem to work well.
As mentioned in another answer, Vim also offers support, and Emacs has an ado major mode, plus some additional functions through ESS (Emacs Speaks Statistics). Finally, if you are looking a Java cross-platform solution (but why would you?), jEdit supports Stata syntax.
If you want support for Stata colored syntax everywhere (e.g. on GitHub), you'll need to write a lexer for Stata and submit it to Pygments. I've asked a question about that. It does not look very difficult if you know enough Python (which I do not and regret).
HTH
Added: links, sections.
Unsurprisingly, Vim supports syntax highlighting for Stata out of the box. See http://www.vim.org/scripts/script.php?script_id=440 and this blog post:
http://www.enoriver.net/stata/2010/02/26/i-switched-to-vim/
Similar to the other folks, my recommendations are Sublime Text and TextMate. They're my favorite editors on Windows and Mac, respectively. If you're a Mac user, I recommend TextMate (It's free, but Sublime Text is not).
You asked for a text editor, but if you also use any HTML editor, you can use Statax useful. (Here is the link to Statax, if it interests you).
This question was asked years ago, but I would like to add another option that is probably already known to more experienced Stata users. However, this may not be the case for new programmers who end up here, perhaps through a search engine, looking to find more information on the topic.
Visual Studio Code is a streamlined code editor, which offers a very flexible environment for programming. Once installed, one can obtain the necessary add-on package for Stata syntax highlighting from the Visual Studio Marketplace. It is regularly updated and the user can expand its functionality using extensions. As such, if someone is programming in more than one language, s/he can keep everything under one roof.
This solution addresses the OP's need to edit files remotely through its built-in Git support. Git is now pretty much the standard in version control. The idea behind it is that one does the work locally and then syncs the copy of the repository with the copy on the server.
Although this is not a command-line solution, i think it provides a great cross-platform development environment. And Git itself has proven to be very fast and reliable.
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 1 year ago.
Improve this question
As some of you might know I am the lead developer of Padre, The Perl IDE. In the first year of its development, Padre became an acceptable text editor with some extra features for Perl development.
I'd like to ask the Stack Overflow community for some help in driving the project further to turn it into an exceptional IDE for Perl development. So I'd be glad to read what do you think are the most important features of an IDE that are still missing from Padre?.
Especially I'd be interested in people who currently use Eclipse+EPIC, Komodo, Visual Studio, or any of the text editors for programmers.
The most important feature of an IDE for Perl development (including Padre) is:
an interactive debugger that actually works. E.g. remembering breakpoints, ability to drill down into complicated data structures, and copy (to clipboard) should work on watched variables - including a menu command Copy Special that allows putting it in various formats; say CSV, XML or tab-separated.
The two most invaluable features I find:
line-by-line debugging, watchpoints, breakpoints, and so on, so I can properly debug my code.
code completion so I don't have to go looking up docs (even online).
OK, here's my third answer, although I hate to say it.
The competition is pretty easy to install. Padre isn't. I tried to update to the latest release today and, once again, got failing tests.
I am a heavy Perl EPIC user and my biggest gripe is not being able to jump to a function that is clearly defined in the current context (usually by pressing F3). It is pretty
much hit or miss at this point.
Stability. People turn away quickly if their editor crashes and they lose their work.
I work with Komodo. I also use other editors but I come back to Komodo most of the time. A good IDE shoud have:
A good Debugger. Breakpoints, watch lists, everything you need.
Remote debugging. Threads debugging capability.
Syntax highlighting including weighted fonts as well ( I was pretty disappointed by Oxygen, for example, an XSLT IDE, where I can not use bold fonts to emphasize reserved terms)
Syntax completion.
Project management tools, preferable extendable by plugins.
Good VCS integration. This is something that I absolutely love in Eclipse: You instantly see what files have local changes and which aren't added to the repository yet. And you get to browse the different versions and have a nice diff view just one mouse click away.
A project manager. It's essential for me to be able to define the set of files and folders that comprise a particular codebase. Sessions are useful but not a replacement.
Testing integration.
Perl has great unit testing tools. When I run my test suite and get a failure, I want to see the code for the test that failed.
Having a good way to jump through test results and see the code for the failed test along with the expected and actual results would be a great boon.
The first thing I look for is some kind of overview of the currently active file. I'd like to see methods/functions and, if possible, the used modules and especially any use base statements.
You solved that pretty well in Padre.
Visual-Studio style refactoring for variables and function names and extraction of functions.
Visual studio searches your whole module for all references and allows you to see all changed lines in case you do not want to change one instance (for whatever reason)...
The question seems more debatable than answerable.
Risking myself of being accused copyright abuser, I will post contents that I remember from the book "Interactive programming environments" by David R. Barstow, Howard E. Shrobe, Erik Sandewall.
It will not be exactly the same, as I have read the book many years ago and I've jotted down it in another language.
PRINCIPLES OF A GOOD INTERACTIVE PROGRAMMING ENVIRONMENT
1: Know the user
+ Know the previous knowledge and practice of the user
2: Minimize the memorization
+ Selection and not characters entering
+ Names and not numbers
+ Predictable behavior: the user should have a previous impression of what the system will do
+ Possible access and changing of the parameters of the system
3: Optimization of operations
+ Fast execution of common operations
+ Inertia of visualization: the screen should change the less possible
+ Memorization of system operation in user's memory
+ The meaning of specific operations should have a simple relationship with the state of the system
+ The system must be prepared to accept more than 10 followed commands per second, so that it can operate on the user's muscular memory
+ The system should be prepared to organize the parameters of a command
4: Engineer for the errors
+ Provide good error messages.
+ Engineer it to remove away the common errors.
+ The system should provide reversible actions.
+ Redundancy: the operations should have more than one way of being done.
+ Integrity of data structures.
The ability to configure and run external (command-line) tools. Plug-ins are great but end-users won't necessarily want to author one just to integrate with an external tool. Allowing users to configure their own tools provides a great deal of extensibility with minimal barriers to entry.
My editor of choice is UltraEdit. It's not an IDE, but through its support for user tools, I've been able to integrate IDE features such as lint, version control, debugging, and more.
This can be possibly achieved via use strict; but could be as well a valuable feature even if not use'd explicitly, namely:
the other day we spent about 10-20 minutes debugging the following behavior:
my %hash;
$hash->{'key1'} = value1;
# on reading in a different module
print $hash{'key1'}; # is, of course, empty, but was so easy to overlook in the code above
resume:
proper Perl type safety brought in by the IDE.
It might be already implemented in Padre, though, as it turned out not in Eclipse+EPIC
I use emacs. I would like a system that helps me refactor code, especially when I'm working on ugly 1999 code that uses the begin-at-the-beginning-go-to-the-end philosophy combined with duplicate-and-modify.
I looked at Eclipse, but I can't work with a system that requires me to create a project before I can make a one-character correction to a file.
I looked at Padre, but it's slow and crashes.
I looked at Kod which claims to be configured by CSS, but I can't find a man page that will tell me where to put the CSS.
Integration of a read-eval-print loop. As a heavy Emacs user, I very much appreciate Sepia. Very useful for trying things out before I commit them to code.
Ability to create and debug XS code.
The ability to use my own choice of editor (which it may have, as far as I know). That has a chance of winning over the vim/emacs people.
I don't know if Padre can do this, but the ability to split the screen is very important to me. As a VIM user, I constantly split my screen to look at another file while coding.
Line ending policies for files, by directory, and project-wide.
So, for a given project or directory, I'd like to make all line endings be LF only. While in another directory I may wish to have a mix of CRLF and LF files.
I work a lot on stuff that goes back and forth between Unix and Win32 environments.
The typical solution of automatically converting all files back and forth as one moves from platform to platform hasn't worked well for me.
When a file gets created in the wrong format by accident, it can be a real pain.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
In particular, I need a more full fledged version of Trac to support robust project management, and task tracking. I went through the plugins and literally found over 50 that looked promising.
My question is to the admins/users of Trac: which ones are indespensible for making Trac feature complete and which ones should be avoided (e.g. stability issues)?
Lots of Trac plugins look promising. Unfortunately only a handful really delivers and even then some of them are not properly supported or maintained. They also tend to conflict sometimes.
I will not recommend anything for project management specifically but these are the ones which made our live so much easier:
TagsPlugin - the most useful one, adds tags support
BreadCrumbsNav - show previously visited pages, saves lots of time
ShowPath - show the breadcrumbs path, useful if you have your pages named hierarchically
CaseInsensitiveWiki - allows entering case-insensitive URLS
Stratistics - show Wiki/SVN statistics
WikiRename - allows page renaming (does not work well with the Tags)
0.10
WebAdmin - pre-installed in 0.11 but before you need to get it separately
My Favorites:
General:
Better editor WYSIWYG: http://trac-hacks.org/wiki/TracWysiwygPlugin
TicketCalendar Macro: http://trac-hacks.org/wiki/WikiTicketCalendarMacro
AccountManager: http://trac-hacks.org/wiki/AccountManagerPlugin
Scrum
- Agilo: http://trac-hacks.org/wiki/AgiloForScrumPlugin
This is the place to watch http://trac-hacks.org/
Besides those already mentioned here, I also found the following necessary:
Announcer - very flexible notification scheme
AutocompleteUsers - handy while typing (existent) user name
AutoLinks - automatically make words not conforming to wiki naming rule but matches existent page name a link
CustomFieldAdmin - make manage custom fields easier
Redirect - handy if you constantly need to make short-hand name wiki pages (like HTML redirects to HyperText .....)
TicketDelete - make deleting, if at all needed, easier
WikiRename - must-have for wiki refactoring
Below are good-to-have:
S5 - directly render wiki pages as slideshow in S5 format, could be really useful for using Trac as the source for presentation
FullBlog - add blogging support to Trac
Vote - cool add-on feature for big team
TracWikiToPdf - transform wiki page to pdf dynamically (however the effect might be all that satisfying)
TimingAndEstimation - neat for tracking time and/or estimation
I really like the BatchModifyPlugin that makes it easy to change more than one ticket at the time.
MasterTicketsPlugin is quite useful for ticket dependncies.
I would recommend against Bitten for CI (Continuous Integration) (see Martin Fowler on the subject) although I am using it.
The task force behind Bitten doesn't seem strong enough to process the remaining tasks. Simply look at the age and the number of posts in Bitten tickets
I don't admin our Trac, and I don't know all the plugins we use. But I co-developed a GUI we use to navigate the tickets and to track time spent on specific ones. It uses the xmlrpc plugin to query ticket information and to write some information back. Extending Trac is really easy this way.
my must-have list of plugins:
http://trac-hacks.org/wiki/AccountManagerPlugin
http://trac-hacks.org/wiki/GitPlugin
http://trac-hacks.org/wiki/TagsPlugin
http://trac-hacks.org/wiki/BatchModifyPlugin
http://trac-hacks.org/wiki/TicketDeletePlugin
http://trac-hacks.org/wiki/XmlRpcPlugin
some may be part of trac since 0.12
and a script:
https://subtrac.sara.nl/oss/email2trac
Apache Bloodhound is a collection of plugins bundled with Trac. It includes some of the individual plugins suggested in earlier answers, like the AccountManagerPlugin.
The major plugins developed as part of Bloodhound are a very robust Multi Product implementation, full text search (based on Whoosh) with better navigation.
Ticket relations have also just been added.
Bloodhound keeps integrating newly released trac versions quickly, and all plugins interoperate as expected because they're purposefully bundled. It's also still compatible with most trac-hacks.
What plugins you will consider must-have depends heavily on your use case.
Must-have plugins if you need more power in creating advanced wiki pages:
GraphvizPlugin
WikiExtrasPlugin
Must-have plugins if you like IDE-style auto-completion and indentation features in the text editor:
TextareaKeyBindingsPlugin
WikiAutoCompletePlugin
Must-have plugins if you use many Mercurial repositories:
MercurialPlugin
HgDirManagerPlugin
Must-have plugins if you ...
... want to archive emails: MailArchivePlugin
... want to track time spent on tasks: TimeTrackingPlugin
... want to plan your week: WeekPlanPlugin
... want to drag cards between stacks: CardsPlugin
...
But if you don't have these use cases, you will not find the plugins valuable.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
The people writing the user manual are not necessarily programmers, and they need a visual editor. A major issue is the internal format of the authoring tool; it should be readable text/html, so it's easy to compare versions of individual pages checked into version control.
DocBook
(source: docbook.org)
Microsoft HTML Help Workshop can be used to create good quality professional CHM help files. All you need is a bunch of HTML files. The tool "compiles" all these and bundles into a single Help file.
The HTML files can be generated using Microsoft Word/Frontpage or even Dreamweaver. You might want to consider source controlling these HTML files.
Latex. Lyx provides WYSIWYM for writing latex files.
At my old job they used a tool by madcap software called flare.
It seemed to work really well.
There are other professional products which allow help file writing and they have support of "context ID" which makes context sensitive help possible. Doc To Help and RoboHelp are these type of products.
A good combination to consider is Subversion, DocBook and Publican.
Version control = Subversion
Content Authoring = DocBook
Publishing = Publican
Optional WYSIWYG = Serna
At the moment, this is one of the toolchains in use by the world's largest provider of open source solutions, and the name behind much of the world's use of Linux-based operation systems in the enterprise market. Most (and close to all) of Red Hat's official documentation is created in such a manner. Same goes for Fedora.
The major "pro" here is that these are freely available tools, with a strong overlap in the market of technical writers. All of which will be able to (but might not want to) write in XML, and picking up DocBook is like picking up HTML in the 90's. Subversion is a very common version control tool, that like DocBook is relatively easy to implement and use. Publican is a great publishing tool that can take DocBook XML, and publish it to PDF, HTML, HTML-single, etc. Obviously your writers can use a WYSIWYG like Serna, but I use snippets in Geany (on Fedora) or TextMate (on OS X) personally.
The major "con" is the perception of technicality. Your writers might want WYSIWYG (and can have it), and depending on your documentation needs, this might be what you end up using. As you would know, there's a market out there for "Technical Writers" who specialize in fixing Microsoft Word styles (and markup), so the arguments for separating "authoring" from "publishing" are based on proven but distinct use cases for organizations that require documentation to be held up to the same standards of the engineering/programming/source production.
Some of the extreme advice you will get comes from people and companies that have been exposed to the value of XML documentation, and especially those in the realms of DITA, where certain multi-nationals have a reputation for acquisitions that are influenced by the format and availability of the product knowledge. there are also the arguments that locking your documentation into a "sticky" or closed format doesn't help the future maintenance requirements. This is where the open source options gain support on a corporate level. Plus, obviously, it's free.
You can use Subversion and MGTEK Help Producer. Help Producer makes help files from Word documents. TortoiseSVN comes with scripts to compare different revisions of Word documents, in Word itself (Word has a version compare tool).
Your users are going to want a visual diff tool that resembles the one they are editing in. If they are just slightly not-technical, DocBook or Latex aren't going to work (I've tried giving my users both, and I even tried Epic Editor as a DocBook editor which is very expensive but didn't work out very well after all). Sticking to something they know (Word) will prevent you many headaches.
I was very reluctant to go this route at first too, because I wanted a solution that was more 'technically perfect', but I realized over time that having happy and productive users was more important. Just saying that I know where you're coming from, but try the Word route - it works much better in practice than all the 'pure' text-based solutions that are out there. Regular users don't like markup based editing.
If you're using Visual Studio, take a look at SandCastle - http://www.codeplex.com/Sandcastle.
There's also a couple of tools that help you build sandcastle files, try searching "sandcastle" on codeplex. One of them is SandCastle Help File Builder (http://www.codeplex.com/SHFB), but I've never used it so I don't know if non-technical users will be happy with that.
Mapcap Flare is the best commercial tool around. Written by the ex-developers of Robodoc
I created a documentation system called Mandown (Markdown/Html/Javascript/file-based relatively linked documents for portability) which would easily go under version control. The visual editor part you would have to figure out separately - I sometimes use HTML-Kit which at least has a preview feature.
See What is the best way to store software documentation?
Here's another tool to check out: Xilize
We are using APT. It integrates well with the CI (standard build artifact) and is more alive than for instance word document. It is also possible to generate PDFs and other formats when needed.