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
I am currently facing a situation where I as an advocate of test driven development have to compete with an advocate of model driven software development (MDSD) / model driven architecture (MDA).
In my opinion, code generation is a valuable tool in my toolbox and I make heavy use of templates and automation when needed. I also create diagrams in UML when I think this helps to understand the inner working or to discuss architecture on the white board. However, I strongly doubt that creating software via UML (creating statecharts and sequence diagrams to create working code not only skeletons of code) is more efficient for multi tier applications (database layer, business/domain layer and a Gui, maybe even distributed). It seems to me when it comes to MDSD, the CASE tooling suddenly isn't just a tool anymore but it is the thing to satisfy: As I see it, on the one hand, MDSDevelopers profit from the higher abstraction UML gives them but at the same time they are struggling with modifing the codegenerator/template/engine to fullfill their needs which might be easily implemented (and tested) if used another tool out of their toolbox (VisualStudio, Eclipse,...).
All this makes me wonder if there has been a success story (suceess being that the product was rolled out in time, within the budged and with only few bugs and parts of the software have been reused later on) for a real world application which fullfills this creteria and has been developed using a strict model driven approach:
it has nothing to do with the the Object Management Group (OMG) or with consultants related to MDSD/MDA/SOA/
the application is not related to Business Process Modelling and is not a CASE tool itself
the application is actively used by end user
it has at least three tiers, including a user interface which goes beyond displaying raw table values and is not one of the common MDA/MDSD examples ("how to model a coffee machine, traffic light, dishwasher").
A tiny, but nevertheless useful testimonial on the use of MDSD has been posted on the Model Driven Software Network:
http://www.modeldrivensoftware.net/profiles/blogs/viva-mdd-follow-up-building-a?xg_source=activity
It is a relatively small app being developed, but still a good example of MDSD in action.
More success stories are listed at Metacase's site (http://www.metacase.com/cases/index.html). Metacase sells MetaEdit+, which implements DSM (Domain-Specific Modeling). DSM is just a form of MDSD.
I am also developing ABSE (Atom-Based Software Engineering), another form of MDSD, very close to DSM. ABSE is outlined at http://www.abse.info.
I used MDA and code generation on an embedded system project using 4 processors connected via CAN. We had over 20 axes of motion and many, many sensors. The system was highly robust and maintainable as the mechanical components were evaluated and modified.
We worked in the models and generated code so the models were always up-to-date. We did a careful domain analysis to achieve subject matter isolation. The motor control required very high performance and so was not modeled or generated. Our network drivers were also hand-coded, and we wrote interfaces that allowed bridge services to send events to any service anywhere in the system as needed (although this was tightly controlled so as to minimize interprocessor dependencies).
Using the method took a bit of discipline, but having working models was great because they can be reviewed by non-software types.
Version control and differencing of the models was a bit of a challenge but we had a small, localized team so we were able to avoid merge issues.
The good people at Pathfinder Solutions (our tool vendor) can help mentor you through the project.
You could also take a look at the slides from previous Code Generation conferences. Several of these talks were from successful case studies e.g. http://www.codegeneration.net/cg2009/slides.php
I am working on one of the project for legacy modernization and its using MDA tool named Bluage. Its for a big healthcare organization and its in production so i could say that its successful. MDA is better in case of legacy modernization as it can generate KDM model from some technologies like pacbase which are going to be out of support.
I worked on a MDSD system that generated admin style web apps in Google Closure. I believe that your question is compelling. Too much complexity and your MDSD system is too hard to use. Too simple and you won't generate apps that are useful in the real world. Where MDSD really shines is in saving developer time typing lots of plumbing style code but how can MDSD remain effective over multiple releases? Requirements can go in many directions. That is the real challenge. I recently blogged about my MDSD lessons learned on that project.
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 6 years ago.
Improve this question
We currently use Cradiator to display the status of our continuous integration (CI) builds from CruseControl.net, on a 42" Samsung television on display high-up in our IT department.
Cradiator is a great starting place, but we're getting to the point whereby we're having lots of projects on there and it's starting to get a bit 'full'.
What I'd like to know is, what do you use to display your build statuses? Custom software? Off the shelf stuff? etc. Alternatively, I'm looking for ideas on how we improve on Cradiator.
I use Hudson, and when I have a chance to dedicate a monitor to it, I'm going to start with this:
http://wiki.hudson-ci.org//download/attachments/37323554/Hudson_1.jpg
http://wiki.hudson-ci.org/display/HUDSON/Radiator+View+Plugin
... after all, if they're green, they don't need to take up much screen space, do they? Imagine if they were all green. People would be just as happy (and just as informed) if it showed a big checkmark and nothing else. So you only really need to highlight the failing ones. Cradiator looks skinnable, and you're already using it, so that's the first thing I would try.
I mentioned several solutions for Hudson in a previous answer:
There are many solutions (all links
below point to working solutions with
Hudson or existing plugins):
Hudson Build Status Lava Lamps
Hudson Ambient Orb
Hudson Do It Yourself Orb
"Red Bear Alert!" - The Hudson Bear Lamps
"Watch the bikes!" - Extreme Feedback with Traffic Lights
Start to smell those code smells
Nabaztag
TuxDroid
Radiator View (ideal for displaying on a screen on the office
wall)
eXtreme Feedback Panel (even better than the Radiator View,
especially for a FullHD flat panel)
Check out the other Build
notifiers plugins for more ideas.
Personally, I have experienced the
bunny, lava lamps, orbs and the
radiator view. They all do the job but
I have a little preference for the
lava lamps. As Jeffrey mentioned in
another answer, it's indeed funny to
race against the wax to fix a build
failure :)
We're currently using the Radiator View that includes now the modifications mentioned in this comment. It's use the space in a very neat way and does a perfect job, even when you have a lots of projects. It's just great.
(source: hudson-ci.org)
Check the link for more screenshots. I miss lava lamps a bit (because they are fun) but the Radiator View provides better feedback IMO.
One idea (and Cradiator does have an issue tracker item for it) is to only showing broken builds.
Another idea, is to monitor multiple configuration sets and switch/fade between them at a set interval.
Our team has 12 projects to monitor, but to get around the clutter we currently have 1 machine with 2 monitors connected. Each monitor has an instance of Cradiator running on it. Doing this and using the RegEx Project Filter feature in Cradiator we show 5 projects on one monitor and a different 7 on the other. This should keep us going until about 15 projects, when the clutter will start to gang up on us again.
Cradiator is open source and the 'skin' concept is relatively isolated, just waiting for you to get your hands dirty in the source code!
In fact, I have just moved the source code for Cradiator to GitHub for a more flexible approach to sharing each other's work. Fork away.
One of the primary goals of radiating build status information into a room is to get developers to respond to broken builds and fix them. Quickly working out who might be responsible for a failing build is important.
What I have experienced first hand at my company is that processing check-in comments and displaying pictures of the users contributing to a build is very effective way of getting developers to react to build failures. People seem to respond to their face on a red bar, and others don't have to be so distracted.
With this in mind, I have developed a standalone build radiator web-app that talks to Jenkins and TeamCity over their REST APIs. CI-Eye is trivial to set up, and will probably give you better results in the workplace than many other plug-ins and radiator apps. Give it a try, and let me know what you think -- I'm quite actively improving it, and welcome any feedback.
CI-Eye is free and open source -- see the CI-Eye wiki for more details.
A good option for continuous integration radiator is Buildron (Mac & Win).
Its supports a lot of builds in same screen, as you can see:
And you can filter builds using a remote control (iOS & Android).
If projects depend on each other somehow or if you can assign some priority (business value?), then I would consider some tree or a map kind of stuff. For 100+ projects it really should be more visible which greens/reds are more important than others. Myself I'm using just the structured web dashboard + systray. Not even email.
Brett, actually Cradiator just added a feature called MultiView to Cradiator - which is one way of fixing your problem of having too many projects showing.
So you can split your projects between separate "views". A view is the combination of URL/Skin & Project Filters.
Each view is shown on a rotation cycle every poll interval (default 30 seconds)
For example, if you have 12 projects, you can set 2 views which show only 6 each.
See the Release Notes for v2.8 for details.
The show only breaking builds feature has been added as well.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 6 years ago.
Improve this question
Where I work we've recently put together what we call the Development Standards Committee which is tasked with improving our procedures, processes, methodologies, tools, standards, and whatever we think would help us become a more effective team.
We've got a spreadsheet of items that we've ranked and are going to start tackling from the top down. We've got things such as better source control (currently on SourceSafe), implement a bug tracker (such as Mantis of FogBugz), peer code review, move to .Net 3.5, possibly move to some form of Agile, do more actual team development rather than single developer per project type stuff, and some other things...
What do you think are some key things that can make or break a development team? What should we add to this list?
Some additional information: We have about 12 people on our windows team, and about fifty in development if you include all platforms. We want to improve as much as possible for everyone, but we're our biggest focus is the Windows team. All of us have been here for a couple of years at least, so most of us know each other and work together pretty well.
The number of people on your team is actually really important here. There are basic things that every team should implement (source code control, bug tracking, etc), but there are things that are different base don team size. Code reviews on a very small team, for instance, can be more informal.
Moving to Agile is a good idea, unless you're particular development environment makes it a bad idea. Also, you'll not be able to do this without support from the people who are using your software.
Consider doing things to ensure that communication between the team is easier and with less roadblocks - do all your members know each other pretty well? Can you work with each other? Do you understand each other's idiosyncracies? Learning to work as a team is much more important than any random process improvements you can make.
Require comments when you check in code (it's great if you can tie commits back to your bug tracker)
Maybe Static Code analysis, like what's built into Visual Studio
Continuous Integration like CruiseControl
Development teams really need good people to start with, that work well together, but this isn't really an item to add to the list. It does however affect my first recommendation, be pragmatic. If you're not encouraging your developers to think about how they work and can drive them selves to improve, it's really hard to lay down a development environment that will do it for them.
Mentor and Training: If you can't do XP, then at least hook up your Juniors with Seniors whenever you can. Not only will you share knowledge but you'll share the context around your projects you own.
Some sort of Continous Integration and regular, tested, working "releases" make wonders for quality.
as better source control (currently on SourceSafe)
If this is Visual SourceSafe -- you need to change this immediately. Try cvs, svn or even something paid like Perforce.
There exists something called Rational Unified Process that deals with your problem (and much more).
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Sight is one of the senses most programmers take for granted. Most programmers would spend hours looking at a computer monitor (especially during times when they are in the zone), but I know there are blind programmers (such as T.V. Raman who currently works for Google).
If you were a blind person (or slowly becoming blind), how would you set up your development environment to assist you in programming?
(One suggestion per answer please. The purpose of this question is to bring the good ideas to the top. In addition, screen readers can read the good ideas earlier.)
I am a totally blind college student who’s had several programming internships so my answer will be based off these. I use windows xp as my operating system and Jaws to read what appears on the screen to me in synthetic speech. For java programming I use eclipse, since it’s a fully featured IDE that is accessible.
In my experience as a general rule java programs that use SWT as the GUI toolkit are more accessible then programs that use Swing which is why I stay away from netbeans. For any .net programming I use visual studio 2005 since it was the standard version used at my internship and is very accessible using Jaws and a set of scripts that were developed to make things such as the form designer more accessible.
For C and C++ programming I use cygwin with gcc as my compiler and emacs or vim as my editor depending on what I need to do. A lot of my internship involved programming for Z/OS. I used an rlogin session through Cygwin to access the USS subsystem on the mainframe and C3270 as my 3270 emulator to access the ISPF portion of the mainframe.
I usually rely on synthetic speech but do have a Braille display. I find I usually work faster with speech but use the Braille display in situations where punctuation matters and gets complicated. Examples of this are if statements with lots of nested parenthesis’s and JCL where punctuation is incredibly important.
Update
I'm playing with Emacspeak under cygwin http://emacspeak.sourceforge.net I'm not sure if this will be usable as a programming editor since it appears to be somewhat unresponsive but I haven't looked at any of the configuration options yet.
I'm blind, and have been programming for about 13 years on Windows, Mac, Linux and DOS, in languages from C/C++, Python, Java, C# and various smaller languages along the way. Though the original question was around configuring the environment, I think it's best answered by looking at how a blind person would use a computer.
Some people use a talking environment, such as T. V. Raman and the Emacspeak environment mentioned in other answers. The more common solution by far is to have a screen reader which runs in the background monitoring OS activity and alerting the user via synthetic speech or a physical braille display (generally showing somewhere from 20 to 80 characters at a time). This then means a blind person can use any accessible application.
So, I personally use Visual Studio 2008 these days, and run it with very few modifications. I turn off certain features like displaying errors as I type since I find this distracting. Prior to joining Microsoft all my development was done in a standard text editor like Notepad, so once again no customisations.
It is possible to configure a screen reader to announce indentation. I personally don't use this, since Visual Studio takes care of this, and C# uses braces. But this would be very important in a language like Python where whitespace matters. Finally, Emacspeak does make use of different voices/pitches to indicate different parts of syntax (keywords, comments, identifiers, etc).
I am blind and have been a programmer for the last 12 years or so. Currently am a senior architect and work with Sapient Corporation (a cambridge-based consulting company creating both Web-based and thick client based enterprise solutions).
I use several screen readers but mostly stick with Jaws for windows and NVDA.
I have mostly worked on the Microsoft platform and visual studio as my environment. I also use tools like the MS Sql enterprise studio and others for DB access, network monitoring etc.
I tried to spend some time with emacspeak but since my work was mostly based on the MS platform, never really spent a lot of time there.
I have also spent a couple of years working on C++ on linux - mostly used notepad or visual studio on windows for all the coding and then samba to share files with the linux environment.
Also used borland C for some experimental stuff. Have recently been playing around with python, which as other people have noted above is particularly unfriendly for a blind user because it is written using indentation as the nesting mechanism. Having said that, NVDA, the most popular open source screen reader is written completely using python and some of the commiters on that project are themself blind.
A particularly interesting question I get frequently asked as an architect is how do I deal with diagrams - UML and visio and rational rose etc. Visio is probably the most accessible diagraming tool out there. I was able to write jaws scripts to read rational rose diagrams for me. I've used a tool called T-dub (technical diagram understanding for the blind) developed by some german university for accessing UML 2.0 diagrams. Have used a java-based ugly tool called magic draw for doing model-driven development and was a commiter on the androMDA project and helped develop the .Net code generator from a UML model.
In general, I find that I thrive most in a team environment where I can work on my strengths. For example, while a diagram is extremely useful to communicate/document a design, the actual design process involves a lot of thinking and brainstorming and when the design has been thought out, one of your team mates can help you quickly put together a neatly drawn picture out of it.
People incorrectly mis-construe the above to be lack of independence or ability while I see this as pure inter-dependence -- as in I am sure that the team mate alone could never have come up with that design on his/her own and in-turn, if I depend on him to document the design, so be it.
Most hurdles I face are tool-based inaccessibility. For example all oracle products have been progressively declining in accessibility over the years (shame on them) and a team environment basically allows me an extra layer of defense against these over and above my screen readers and custom scripts.
I am a blind developer and I work under Windows, GNU Linux and MacOS X. Each of platform has different workflows for blind users. This depends on the screen reader that the blind developer uses.
Development tools are not completely accessible for blind developers. I can type code and use compiling functions in all IDEs but there are many problems if I have to design an interface using designing tools as Interface Builder, XGlade or other. When I was developing with Borland Delphi I could add a control, a Button for example, and I could modify each visual attribute of the control using object inspector window. Many IDEs use object inspector windows to modify visual and non visual attributes but the problem for a blind developer is add new controls because the method to add a new control consists of dragging and dropping a control from the palette to the canvas. Visual studio 200x uses alternative methods to do this but the interface of the IDE changes in each new version and this is a big problem because screen readers for Windows need special support, using scripts, to identify each area of some non standar applications. A blind developer can use Visual studio 2008 with his screen reader but when a new version of this IDE appears he has to wait for a new version of scripts for this version of the IDE.
Xcode with Interface builder has no alternative for dragging and dropping tasks yet. I asked it to Apple many times but they are working in other things. I published 3 apps in the App store (Accessible minesweeper, accessible fruitmachine and Programar a ciegas RSS) and I had to design all the interface by code. It's a hard work but I can manage all features of each control.
Eclipse has an accessible code editor but other development tools as debug console,plugins for designing or documentation area present problems for assistive tools for blind users.
Documentations is a problem for blind developers too. Many samples and demonstrations use images to show the explanation (set the environment settings as you can in the picture)
I think the question is not being blind. The question is the companies and development groups think accessibility affects final software but it doesn't affect development software. They think a blind user should be a client but a blind user can't be a development mate.
Blind associations ask accessibility for products and services but they forgot blind developers. Blind people can work as lawyers, journalists, teachers but a blind developer is a strange concept even for the blind. Many times I feel alone because some blind friends of mine can't understand my work.
You can read my opinion about this issue in this article, in Spanish, in my blog http://www.programaraciegas.net/2010/11/05/la-accesibilidad-en-crisis-para-los-desarrolladores-ciegos/
there is a translation tool in the web page. Sorry but I didn't translate it.
Emacs has a number of extensions to allow blind users to manipulate text files. You'd have to consult an expert on the topic, but emacs has text-to-speech capabilities. And probably more.
In addition, there's BLinux:
http://leb.net/blinux/
Linux for the blind. Been around for a very long time. More than ten years I think, and very mature.
Keep in mind that "blind" is a range of conditions - there are some who are legally blind that could read a really large monitor or with magnification help, and then there are those who have no vision at all. I remember a classmate in college who had a special device to magnify books, and special software she could use to magnify a part of the screen. She was working hard to finish college, because her eyesight was getting worse and was going to go away completely.
Programming also has a spectrum of needs - some people are good at cranking out lots and lots of code, and some people are better at looking at the big picture and architecture. I would imagine that given the difficulty imposed by the screen interface, blindness may enhance your ability to get the big picture...
Hanselman had a really interesting podcast with a blind developer recently.
I worked for the Greater Detroit Society for the Blind for three years running a BBS tailored for blind access and worked with a number of blind users on how to better meet their needs, and with newly blind users to get them acclimated to the available hardware and software offerings that were available at the time. If nothing else, I at least learned to read Braille as a hedge against the case where I ever wound up in the same situation!
The majority of blind computer users and programmers use a screen reader of some sort. Jaws in particular is popular. Fortunately, most major applications these days offer some form of handicapped access. You may have to tune your environment slightly to cut down on the chatter, e.g. consider disabling Intellisense in Visual Studio.
A Braille display is less common and is comparatively much more expensive and can show 40 or 80 columns of text, and can be used when exact positioning/punctuation is important. While a screen reader can be configured to rattle off punctuation, a lot of people find it distracting, and it is easier in many cases to feel your way through it. Jaws can be configured to drive the display, so you're not juggling accessibility applications.
Also, a lot of legally blind users still have some modicum of sight left to them. Using high contrast backgrounds and the magnification functionality can help a lot of these users.
Using ToggleKeys in Windows will let you hear when you accidentally tap one of the modal 'caps lock', 'num lock', 'scroll lock', etc. keys as well.
I know at least one Haskell programmer who uses a screen reader and who explicitly programs without using Haskell's layout rules, and instead opts to use the rather non-idiomatic, but supported {;}'s instead, because it is easier/less distracting for him to get his screen reader to read off punctuation than for him to figure out exact indentation that complies with Haskell's layout rules. On that same note, I've heard some grumbling from a couple of blind programmers about when they have to write Python.
Ultimately, you learn to play on your strengths.
I can't recall the source, but I've heard/read about a form of audible syntax "colouring" - so that instead of a string assignment being read as
foo equals quote this is a string quote
the string part would be read with a different pitch or voice to make the separation of elements clearer.
One place to start is the Blinux project:
http://leb.net/blinux/
That project describes how to get Emacspeak (editor with text-to-speech) and has a lot of other resources.
I worked with one person who's eye sight all but prevented them from using a monitor - they did well with Screen reader software and spent a lot of time using text based applications and the shell.
Wikipedia's list of screen reader packages is another place to start: http://en.wikipedia.org/wiki/List_of_screen_readers
I'm a postgraduate student in Beijing,China. I major in computer science and a lot of my work is programming.
I am born with low sight, I need to use magnifying tools to see fonts on screen clearly. I use microsoft's mgnify tools on windows and use compiz's magnify plug in if on linux. I usally set the tool to magnify as three times many as the original font size.
For me maginify tools is ok, the main problem is the speed,I have to move mouse to keep cursors follow the text I'm looking at, microsoft's magnify provides a option of "auto follow the text edit points",that set me from continuously mouse movement when editting or coding. But it doesn't always works because of the edit software or IDE may not support that.
Magnifying tools on linux are hard to use. The KMag come with KDE has a terrible refresh rate which make my eyes unconfortable, compiz's magnifying plugs which I'm using now is OK,but has no function of auto focus(focus auto following).
iOS provides quite perfect solution for me with full screen magnifying, especially on ipad's 9.7 inches screen. there auto focus is not necessary because I hardly use them to code or do other edit stuff.
Android provides very little accessibility functions, only like shake feedback, which is useless for me.
there is no any kind of good magnifying tools on android , not to mention advance function like full screen magnify on iOS.
I used to study Qt, want to build a useful magnify tools on linux, even on android. But hardly have some progress.
When I was in grad school, we had a member of our research team who was blind. He was a bit older, maybe mid-40s. He told us about how he programmed his first computer (which was well before text-to-speech was common) to output the contents of the screen in Morse Code. To overcome the obvious chicken-and-egg problem, he had to completely rewrite the code each time through from scratch until it was working well enough for him to have it read back to him.
Now he uses text-to-speech, though he plans the code very thoroughly before actually writing any of it, to minimize the debug loop.
He was also pretty good at giving PowerPoint presentations that, despite his lack of sight, were just about as well formatted as any sighted presenter's.
This blog post has some information about how the Visual Studio team is making their product accessible:
Visual Studio Core Team's Accessibility Lab Tour Activity
Many programmers use Emacspeak:
Emacspeak --The Complete Audio Desktop
Back in New Zealand I knew someone who had macular degeneration, so was partially sighted. He's a very talented programmer and wound up using Delphi because he could work by recognizing word shapes This was easier to do with a Pascal-like syntax than a C-ish squiggly bracket one. He has a web site, but doesn't seem to mention macular degeneration at all, so I won't name him.
I'm blind and from some months I'm using VINUX (a linux distro based on Ubuntu) with SODBEANS (a version of netbeans with a plug-in named SAPPY that add a TTS support).
This solution works quite well but sometimes I prefer to launch Win XP and NVDA for launching many pages on FireFox because Vinux doesn't work very well when you try to open more than 3 windows of FireFox...
As many have pointed out, emacspeak has been the enduring solution cross platform for many of the older hackers out there. Since it supports Linux and Mac out of the box, it has become my prefered means of developing Windows egnostic projects.
To the issue of actually getting down syntax through an auditory one as opposed to a visual one, I have found that there exists a variety of techniques to get one close if not on the same playing field.
Auditory icons can stand in place for verbal descriptors for one example. You can, put tones for how far a line is indented. The longer the tone, the further the indent. Since tones can play in parallel with text to speech, the information comes through in the same timeframe and doesn't serialize the communication of something so basic.
Braille can quickly and precisely decode to the user the exact syntax of a line. This is something more useful for people who use braille in daily life; the biggest advantage is random access to the contents of the display. Refreshable units typically have router keys above each character cell which can place the cursor to that cell. No fiddling with arrow keys O(n) op vs O(1) access.
Auditory dimensionality (pitch, rate, volume, inflection, richness, stress, etc) can convey a concept (keyword, class, variable, error, etc). For example, comments can be read in a monotone inflection...suiting, if I might say so :).
Emacs and other editors to lesser extents (Visual Studio) allow a coder to peruse a program symantically (next block, fold block, down defun, jump to def, walk up the parse tree, etc). You can very quickly get the "big" picture of the structure of an entire project doing this; with extensions like Cedet, you can get the goodness of VS/Eclipse/etc cross platform and in a textual editor.
Could probably go on and on, but that in a nutshell, is the basis of why a few of us are out there hacking away in industry, adacdemia, or in our basements :).
A group of students from Southern Illinois University Edwardsville and Washington State University are working on a programming language for the blind:
http://www.youtube.com/watch?v=lC1mOSdmzFc
harald van Breederode is a well-known Dutch Oracle DBA expert, trainer and presenter who is blind. His blog contains some useful tips for visually impaired people.
What in the world would a braille keyboard even be??
There are such things as braille writers but you would never use one as an input device for a computer.
If you're simply talking about a keyboard with the braille symbols on it this would also be a very bad idea. You're going to have a lot more keys to reach while typing and it would still be slower.
Touch typing is NOT a visual skill, a blind person can do it just as well as a sighted person.
I think that this would work well in extreme programming using the pair programming principle. If you're making software for blind people, who better to make it then someone who would literally be in touch with the business requirements, so I don't think it's very far fetched at all.
As for writing code, well unless there was some kind of feedback I think a person may struggle with syntax. Audio feedback may help to a point though.
NVDA is a good open source screen reader for win.
What about inventing some kind of device that you plug in a usb port and that would be basically a "sheet of rubber" that would modify itself to show brail of your code, allowing blind people to read it instead to hear it?
There are a variety of tools to aid blind people or partially sighted including speech feedback and braillie keyboards. http://www.rnib.org.uk/Pages/Home.aspx is a good site for help and advice over these issues.
Once I met Sam Hartman, he is a famous Debian developer since 2000, and blind. On this interview he talks about accessibility for a Linux user. He uses Debian, and gnome-orca as screen reader, it works with Gnome, and "does a relatively good job of speaking Iceweasel/Firefox and Libreoffice".
Specifically speaking about programming he says:
While [gnome-orca] does speak gnome-terminal, it’s not really good enough at
speaking terminal programs that I am comfortable using it. So, I run
Emacs with the Emacspeak package. Within that, I run the Emacs
terminal emulator, and within that, I tend to run Screen. For added
fun, I often run additional instances of Emacs within the inner
screens.
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
What software do you use to manage Scrum software development ?
We've tried Tackle and VersionOne (both free) so far and they are good except for the fact that it's difficult to track work in progress. For example, if I have a task that I estimate will take me 8 hours to complete, I've done 4 hours of work with 4 hours remaining, the task is always reported as 8 hours remaining until it is marked complete, at which time it falls to zero.
I'd like to use a tool that will allow me to take an accurate work at the teams WIP at the end of each week and see how much impact that work has had towards a deadline along with completed tasks.
Thanks for your input!
I recommend a white board and excel spreadsheets. The whiteboard has story cards (index cards) , where the work in progress is tracked. The story card starts out with say 8 hours, and as the work progresses decrement the number on the card. At the end of the day, put the numbers in the cards to a spreadsheet.
The whiteboard is visible all the time, and gives the whole team visibility on how the work is progressing.
This question was asked recently:.
Everything from Excel to VersionOne to Scrumworks to BaseCamp was mentioned.
Personally, though, we use a heavily customized Excel sheet, whiteboards, index cards in a variety of colors and a large corkboard.
You also might want to check out Mingle. It's a tool developed by ThoughtWorks, a company that only does Agile.
We've looked at most of the tools out there and ended up with Scrumwise. We've been using it for a while now, and it's incredibly easy to use, and does what we need. It uses the remaining time on each task to compute the burndown etc.
I note that no one has pointed out the misunderstanding of WIP (work in progress).
In agile, “it is not done until it is done”.
While most people see work done as a good thing, it is not. WIP represents investment that can not yet be realised. This is an important part of Agile, but made more explicit in Lean/Kanban.
If you track work done you will encourage developers to work on several things at once, getting everything to “80%” complete. At the end of the project you will spend 4 times more (80% of your time) in “bug fixing”, doing the last 20%. You will look like you are ahead of schedule, but you will over-run.
Also after one sprint, if work packages are small (they will be if you are doing scrum), then the error from not adding part done work to work done is insignificant.
Therefore: Track WIP separately from work done and try to keep it low.
Compromise
As a compromise, you can track part completed with the following rules:
Only track one task per developer. (probably the biggest)
Add a cap, maybe 1/2 sprint.
Discount the rate, maybe 50%, if it is 80% done then report 40%. (tweak the discount rate when you have evidence but don't let it be as high as 100%)
OnTime recently added support for Scrum management (disclaimer: I work for them and helped build the product). :) We also put together an intro video for Scrum if you need more information: Video.
I've been working on an open source web based tool that you can install on site or use our hosted version. We've got sub-task tracking and a real time planning poker feature.
http://www.scrumdo.com/
I was looking up SCRUM software and found this old topic - just my two cents ....
I worked on a project in a healthcare domain for about a year and we used Version One. I am sorry to say, it was perhaps the most despised tool in the project. The testers especially, loathed it. Neither did we developers like it as it was pretty clunky/slow and generally pretty lethargic. We always had excellent customer Support from V1 but the tool just didn't cut it for us.
I am now working in a different project and we are using www.scrumwise.com - and so far so good....
VersionOne does let you change the estimates as you go - the burndown report wouldn't work otherwise. You may be hiding the estimate column or have it set to read-only - click the spanner on the right to list available columns and make sure that the estimate/ToDo column is editable.
We've found it to be rather good, though their odd insistence on customised controls breaks in Chrome.
I would suggest checking out OnTime's Planning board because using excel and an actual white board takes away from actual development time when you can automate the process with software..
I answered a similar question at https://stackoverflow.com/a/16667842/1810290 and I thought of sharing it here as well.
If you are looking for an online scrum tool, then you could have a look at Flying Donut. It is a new online product, and I've used it in my projects with great deal of success. There is a nice way of organizing your backlog, and its GUI is clean with quick response times. It provides different iteration views for planning, execution, and review.
Disclaimer: I have been using it for many months, since I helped building it.
ScrumWorks is nice for small teams. And free, too, for the basic version. We have about 30 developers with multiple projects/iterations/etc. Some basic burn-down charts, good for "yesterday's weather", etc.
Check it out at:
http://danube.com/scrumworks/basic
I think RallyDev might be worth checking out for you. Unless I'm mistaken the way that it tracks time will not cause the issue that you mentioned above.
We have been using it on our project for several months and have grown with it to where the team enjoys using the project.
We use Scrum for Team System which is excellent, but you do need to be using Visual Studio Team System to get it!
I've used this Index card generator, but I see now that there is a newer version link that only uses Excel
I also like their Planning Poker when trying to get estimates.
Just saw this, maybe in a another stackO q/a, https://scrumy.com/demo
Check out Scrum Pig at http://www.bellacode.com. It is a great Windows tool for teams collaborating together when using Scrum.
We use RallyDev for scrum management system. And I found it very much handy.
No-one has mentioned JIRA, is that a cost/OpenSource thing?
I've used JIRA for the last 3 years and have found it to be an excellent tool.
We also use a physical board with a google spreadsheet that serves as an online replica. It works really well and doesn't really add any overhead if everyone gets in the habit of maintaining both. I've blogged about it and included a sample spreadsheet:
http://www.littlebluemonkey.com/blog/online-scrum-tools-part-1-the-scrum-board/
We have used XPlanner. It's simple, but does it's job pretty well. Especially Developers get a nice overview for their current status.