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 would like to know what kind of tool you use for writing your specifications. I think it's essential to use a tool that supports some kind of plain text format so that one can control the specification with a source control system like SVN. For the specification as for the code as well, it's important to have a history of all changes.
At present we write our specification in a XML format. TeX would also be an alternative, but it's hard for people who have never been working with it.
So let me know, what kind of tools or formats you use for specifications.
DocBook edited with XXE, translated to pdf with xslt when needed to be sent to clients.
Best change ever, so much easier to write, so much easier to merge, and when it's converted it doesn't look so godawfully unprofessional as MSWord.
Plus the structured document style is already there, unlike bloody word which you have to fight with to get working.
We used TeX (MikTeX) and it was perfect because:
plaint text - edit in Vim/Notepad - just everywhere
powerful formatting using predefined macros one of us did
onclick generation to PDF
The only problem was to get diagrams (from ArgoUML) in.
At another project I saw using Word templates - awful stuff directed from above.
I'd consider using something like wiki/forum on intranet. Imagine using GoogleDocs - there is versioning, it's online.. but not applicable for commercial development.
At work a lot of our documents go under Sharepoint or some other document system that really slows down the "release" of a document. This means there are copies of the documents all over the place and getting someone to properly release something is a headache. Due to this I normally received specs in power point or scrap paper. So I put up a wiki (Media Wiki) at work that we now keep all project specs in. This allows them to be viewable by anyone in the company and editable by our development group. Sometimes a developer will ask the boss for a clarification as they pass by or whatever and the developer can update the spec themselves which I think is a huge advantage. Also, when people update a spec with new information using the history it is very easy to see what the most recent changes were - meaning I can see what was happening before and what needs to happen now, which I think is a huge advantage.
I still keep a spec that was scribbled on some notebook paper up on my wall as a reminder.
I've come to use Docbook for all such things. It's easy, flexible, and will generate html, tex (and thus pdf), etc.
Microsoft Word. I know it doesn't meet with your requirements but in every job I've had I've used Microsoft Word for the specifications. You can, and I have, put Word documents in a source control system - The only thing you lose is the ability to diff between documents. Although I do vaguely remember reading somewhere that there are diff tools for word that can be used.
At work we use a wiki because they are great for collaboration, but Microsoft Word will work.
You can actually diff two different versions of a Word document using Word itself - it uses the "track changes" feature to show the differences. (If you don't believe me, try diffing two versions of a Word document using TortoiseSVN.)
For long documents, I actually prefer Word over the wiki because it is well suited to editing long documents and business folks are more comfortable working with Word documents.
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.
On my first job interview, I was asked why did I build my own CMS? Why not to use one of existing CMS, Wordpress, Joomla, Drupal...? At first, I was stunned. I couldn't immediately recall all of my reasons for building my own CMS, but this was definitely one of the main reasons: It's my code and if I want to change something in that CMS (which I often have to do, because each website I build needs CMS with different functions) it's not a big problem. For some time I've been using Wordpress and one of the main things that distracted me from using it was discovering bugs in code that wasn't written by me and this bugs were often, especially if I made some changes to CMS or added a plugin...
Here, I can find these 8 reasons why NOT to build own CMS:
It won’t meet users’ needs
It’s too much work
It won’t be a standard solution
It won’t be extendible fast enough
It won’t be tested well enough
It won’t be easily changeable
It won’t add any value
Create content, not functionality
Quote from the same page:
So the main question to ask yourself
is: ‘Why am I really trying to
re-solve a problem that has already
been solved before?’
Well, I definitely agree that it's hard to invent CMS that hasn't been already invented, but on other hand, I think every CMS is (or should be) individual... it maybe won't have a million of functions, it will have 3 functions but their usage will be clear (to a user) and do all that one site needs to have. I think also that it is not good to give to a client a CMS with a lot of functions that are never used and it looks probably more professional when website and CMS together look like one product.
I would also like to comment some quote parts:
"It’s too much work" - I agree, but when using existing CMS and customizing it to website needs and can sometimes be very hard job or mission impossible.
"It won’t be easily changeable" - I disagree with this one.
What is your opinion on this one, why did you develop or didn't develop your own CMS?
Ile
This is an interesting question that applies to most development, not just when building a CMS.
In general, I would say that it's a bad idea to reinvent the wheel (and most of your 8 arguments are correct in most cases), but there are exceptions. The first one that comes to mind is one from Joel Spolsky, In Defense of Not-Invented-Here Syndrome:
If it's a core business function -- do
it yourself, no matter what.
The point is, if you're making your money directly from building content management systems, you should not take one from someone else and tweak it until it fits you. You'd rather be in full control over your own product.
Edit:
Also, don't forget that the urge to reinvent things stems (among other things) from a fundamental law of programming:
It's easier to write code than it is to read it
This does not mean that we should take the road that appears to be easier but it explains why we fall for it. Take the challenge and actually read some code, rather than write it, from time to time.
I would build a CMS because it can be fun and a great learning experience.
However, any open source CMS can be customized to any client's need. The biggest problem is that you have to understand how that CMS works in order to be able to change it well.
Either way you would be faced with quite a big task, but I must agree with those who say that you shouldn't start from scratch (unless you are doing it to learn some new technology) exactly for the reasons stated in your question... As they say, don't reinvent the wheel unless you want to learn about wheels.
I've found it works when the context of the project is larger than just a 'content site'. I've worked on a number of real estate sites where the bulk of the content is coming in from data feeds, or already existing in databases that have had their structure set up long before you were involved. Really, we only had a handful of BS 'content' pages that made up the site that were rarely updated. What they really needed was a simple interface to data entry. It was far easier to build some one off components than try and shoehorn an existing system on top of an out of the box CMS.
Like others mentioned though, you must consider overall requirements. Is there workflow involved? Dynamic navigation? Then I'd start leaning more towards out of the box CMS's, but many times people say they need a CMS, when they really just need a WYSIWIG interface to a database. But sometimes not...
It seems to me that the biggest reason NOT to build your own CMS (besides security issues) is lack of support and upgrade path. I consider it a disservice to clients to put them on a custom CMS and then have to rely on you only support and updates. Even worse is having them pay for the development of the custom CMS - they are paying you to reinvent the wheel no matter how simple the site requirements are.
There are plenty of CMS options out there that will allow you to add your own custom extensions if your requirements are beyond what is built in.
The best reason (possibly only) to build a custom CMS is to learn a language well. Building a CMS is a great way to learn web development, but it's not a great way to service your clients.
As a team leader that is always being pushed to do more with less, I too ask the question "why would you write your own?" There are more CMS packages out there than there are programming languages and I find it difficult to believe that you cannot find one that meets most (if not all) customer, business and cost requirements.
If you find that code changes are needed, opt for an open source solution, make your changes and share as needed or desired.
I do know that many times a CMS systems is NOT what is needed. Many customers need a Content Editing System. What I mean is that someone technical puts a site in place and the customer adds/edits/removes pages. The pages are already well designed and formatted. In these cases, I can see where it may be quicker to design & implement something from scratch rather than chopping down a CMS with access rights or removing/hiding functionality.
Unless you're building one for the experience, there's only one real reason for building your own: It's cheaper and/or easier than using one on the market that meets your requirements.
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 looking for a Component CMS solution that is compatible with IBM's DITA in terms of preserving the document hierarchy/structure created in DITA (ditamaps).
I am not necessarily looking for an open source solution.
Other requirements would be:
- file migration
- XML support (ingestion, editing, export)
- PDF support (publishing)
- Workflow management
- Localization support (managing versions across locales)
- Output tagging
As you are looking at CCMS, be sure that you consider the following factors:
How easy is it to get your content into the system?
How easy is it to get your content out of the system?
Does the system use proprietary mechanisms for filtering, rather than support for DITAVAL that is part of the OASIS standards?
Part of the beauty of DITA is that if you follow the standard and do not use proprietary mechanisms, you easily can exchange content with business partners, move to another CCMS, if you needed, and so forth.
Older CCMS use proprietary mechanisms for some things. It's entirely understandable, since they were developed before DITA was a standard, and so have legacy customers with implementations that they must support.
It's a bit dangerous (a lot dangerous) to be choosing something like a Component CMS based on questions on a forum like this, but as long as you're asking you could look at things like: SDL Trisoft, IXIASOFT DITA CMS, Vasont, XDocs, or DITA Exchange to get an idea of what is out there. CCMS systems are vastly different from each other both in price and functionality, so things like:
Number of users
Distribution of users
IT 'religious affiliations' (e.g. SharePoint addiction, Linux)
Use of DITA features like Conref, KeyRef, SubjectScheme
Versioning flexibility requirements
Translation management
will all greatly affect the decision making process. We tend to spend time with a client before making solid recommendations so this is simply something to get you started in your research.
PS - As you may know Arbortext is not a Component CMS at all, it's an editor.
Sorry for not understanding the following thing, from the question.
[file-migration] What is the current format?
If it comes as (DITA) XML (or can be migrated to XML), the following procedure might be a solution:
[Import] Import the (DITA) XML into a Version Control System;
[Edit] From there it is easy to modify by multiple people;
[Export] Always possible, from CVS system;
[Publishing] Automatic PDF generation (DITA Open Toolkit);
[Localization support] Use branches for the different languages;
[Tagging] Tag a final release, when it is is published.
See also the What is the recommended tool chain for formatting XML DocBook? as these same suggestions can be used for a DITA tool chain.
IBM built DITA on Arbortext. Arbortext was the only vendor to be a charter member of the OASIS DITA Technical Committee and they continue that activity as PTC. (Arbortext was acquired by PTC in 2005).
Arbortext also supports DocBook (since conception), S1000D, and custom doctypes with no customization of the application required.
Happy to talk more about this offline.
If you are still looking for options you should check out easyDITA (http://easydita.com)
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.
As an artist and musician, I often want to sit down and just let the code roll like a piece of free-form poetry, but I've found that doesn't work as well as when I have a set goal in mind. I've been experimenting lately with setting up tiny, fun goals for myself, not unlike how an artist would sketch a quick still-life, but I wonder...
What do others do when they want to code for fun, without the bondage of an already-committed project?
Design work, I find, flows much easier than just coding. I find that coding is often more of just implementation of a good design; I really like to just sit down with a pad of paper and a pen (and likely a bottle of wine) and work out an interesting design.
Project Euler is where I'm having fun at now. I can go at my own pace and work on the problems that interest me. Also, work in any language I choose.
Write documentation when coding doesn't come easy - coding will quickly seem much more appealing!
Going for a walk outside.
I tend to map my idea or build a structure in a MindMapping tool like MindMeister. And it's great for a team because it can be edited in real time by multiple persons!
I like to pick up a new language and learn how to express ideas in it. This usually has the benefit of showing me what I like and don't like about the languages I currently use. I usually pick some little tool project I've been wanting to do. Using the new language angle get's me motivated
My most recent 'new language' is Scala, in this case it will likely become a langue I use.
I like writing on whiteboards. Great for db diagrams, task lists, feature lists, (other lists,) random ideas, notes, etc. (db diagrams being the biggie for me)
Python is great for just getting things going on an idea and having the language (usually) behave like you would expect.
While it may have its drawbacks, it sounds like a great fit for what you are describing.
So to answer your question, the Python Challenge is entertaining and often gets me thinking about little things that would be fun to code, probably because it exposes you to different types of problems.
I like to code.
I like to find something interesting, code it and then see it works.
It does not have to be a project per see, it's good enough if it does something, like use Google api to get picasa albums, change song in iTunes or get details of current iTunes song, automate downloading of document from web site that is behind login and requires cookies and all that stuff, data parser in python, simple app on Mac, core data application, google codejam problems, topcoder.com problems ...
I like to learn new features of some language or some new language/technology/patterns/tool :-)
Usually I will work in Photoshop for a while. Get creative and try to come up with a new design that's not constrained by any code. Maybe even find something inspiring on the web for some new design ideas... then try to implement the design in code. That's the fun and challenging bit.
Use the REPL.
You figure out broadly the sort of thing you need to do - what APIs you need to use, what data structures you need to handle - and then prod them interactively until they start making sense. A ton of languages I use now have REPLs: Ruby, Python, Scala, Java (BeanShell, or JRuby/Jython etc.), C# ('csharp'), PHP (Facebook have made a REPL for it), Smalltalk (GNU gst) and, obviously, LISP/Scheme.
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 4 years ago.
Improve this question
I am working with a small team (2 others) of developers that are geographically dispersed, and I'm looking for good ways for us to collaborate on specs... We're thinking we might use Google Docs to write the spec in so we can all have access to modify it in a central location.
What have you done? What good ideas do you have?
If you have an intranet or VPN, I would actually consider installing and using a small Wiki for these specs.
Compared to Google docs you get:
Much better versioning and change tracking (IMHO)
Much easier to start new documents for subsections
An actual markup rather than WYSIWYG (a matter of taste, I prefer LaTeX to Word).
Possible to attach variety of other file types
Very easy to backup
Very easy to create an offline version
You don't have to worry about storing sensitive materials elsewhere.
The disadvantage is that it is not WYSIWYG, which may or may not be an issue to you.
Of course, you can pick a Wiki implementation that supports a better editor, and possibly even a synchronous collaboration one.
Google Wave - exactly what it's meant for - collaboration
IMHO, a word processor is the wrong tool for a programmer. A spec should be written in a plain text editor, and utilize lightweight markup such as reStructuredText, AsciiDoc etc.
The benefits of such an approach are:
There are excellent tools to manage plain text, that are already in the hands of programmers (VCS, automated build systems, diff, patch, programming editors, grep, etc.)
A markup language allow for expressing intent rather then formatting.
That in mind, a Wiki seem to be the obvious choice.
Personally my tool chain of choice is:
reStructuredText as the markup language.
Trac as a Wiki
Firefox + the it's all text extension
Emacs + rst-mode
The choice of technology is one issue and Google docs is a good choice IMHO. But the real challenge is how to manage the process e.g. divide the tasks.
My suggestion is to first make sure that the platform and all related technologies are decided-upon as best as feasible. Then, compose a a thorough table of contents. A well-designed TOC will allow you to divide tasks properly and not "step" on each others' work. From then on you each "flesh" out your assigned sections as well as review each others' work.
In effect, each TOC subsection becomes an atomic unit of work that can be assigned and maintained by an individual who is also accountable for said section(s).
Good luck!
I think it depends on
How heavily into writing the specs you all are
If you're likely writing at the same time
Whether you intend to publish the specs.
Google Docs is nice and easy to get started with. It's also great that you can now export folders all at once. Still, for something that's going to be published to the web, a wiki or general cms is a better presentation vehicle. A wiki will also integrate with your existing site.
If you've got small specs, primarily written by one person then use whatever tool is available where you're hosting the project code or website. If you're not likely to be editing at the same time then a wiki is good.
I've done the wiki thing, the passed document thing and the Google Docs thing.
The wiki thing has a low starting effort and lasts a pretty long time. At a certain size it does get to be a pain.
The passed document thing (writes, email, edit, email, etc) only works while one person is starting everything up. As soon as there are even minor edits then it sucks.
The Google Docs thing is fine until you have several docs and several editors or want to publish it online.
hth
This isn't programming related, but I've personally used Google Docs to write shared documents and found it easy to use.
I would suggest enabling Google Gears however, in the event that the Google servers go down momentarily or an internet connection isn't available.
For writing specs collaboratively, you could try Gingko.
It's a card-tree editor, which means it's a mix between index cards and an outliner, with real-time collaboration and full Markdown support (as well as basic LaTeX).
We are still missing several features (version history, comments, etc), but for some the benefits of having everything in a tree structure outweigh these drawbacks.
Writing specs with it is great, because you can create a card for each user story, and drill into it as much as you like (and organize them into categories if you'd like).
http://gingkoapp.com
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 have to choose a content management system to allow dynamic updating of website content. The amount of configuration required and the learning curve with most of these systems really seems to be a lot more than what should be necessary.
I have almost set the site up with Alfresco SURF - but I just find that it makes simple things harder than they ought to be.
I have heard of Drupal, Joomla and Plone - but what I am hoping for is something that is very simple to set up and use. I have heard these are not.
We just need to be able to change things like dates of upcoming events etc. navigation template changes don't need to be supported (but if it's they are and the software is still easy to use then it's a plus).
Can you recommend only very simple to use apps, or explain if there is some reason what I am asking for cannot exist.
Try Wordpress - it's not only suitable for blogs but also as a CMS if you have very simple requirements .
To make installing much easier you can try a BitNami stack. Drupal and Joomla are there.
Basically they are installed as stand alone instances that are meant to not interfere with other systems you have in place (installing their own DB and webserver).
Have you had a look at ModX? You can have it installed in quarter of an hour and have a working site in a couple more and there are loads of tutorials floating around for it.
Drupal is very easy to use (I know since I run my personal site and my wifes site on it) - the modules install is really extracting a folder. And there is a great system internally which tells you about updates for everything.
Install is very easy now (as hard as installing an app) on IIS with the web platform installer which Microsoft released at Mix. If you want the manual approach it is basically create empty database, extract files, go to site, follow prompts. Very simple too, but the web platform installer handles getting pre-requisites for you, and the config of the server.
I believe Joomla is also on it, but I have not used it.
BTW what I did for my wife's site to make it easy for her was to use Drupal and setup the modules that make it useful, then I created all the pages for her and setup Windows Live Writer on her machine which she uses to edit the pages. This way she controls the content but she doesn't have to know anything about websites. Her site is not a blog, it's a normal business-y site, but using WLW makes it easy.
i would use wordpress for this sort of thing. it is simple to install and is quite easy to use. you don't have to use the blogging part of it
the learning curve with most of these
systems really seems to be a lot more
than what should be necessary
I understand. I've felt the same way when I've tried to use one. There is a lot of terminology and configuration (install, user setup, access rights etc) to go through if you only want to throw up some simple information.
If I were you I'd just use a wiki. The advantage of this is you can create a flow however you want and not worry about the rules of the CMS system. And you can take it wherever you want later on. E.g. Python wiki.
The two wikis I'd recommend are MoinMoin because it is very well presented (e.g. Python wiki), easy to use (full WYSIWYG editor option), customisable (CSS etc) and uses flat files (so no DB admin or hidden content in SQL). Its written in Python and I'd recommend using fastcgi or mod_python to make it really fast.
If you don't fancy that, WakkaWiki is excellent. It's PHP with SQL backend though. Easy to setup and easy to grok with good features (e.g. embedding mind maps).