|
Q4E, the maven integration plug-in that has brought WTP support and Dependency Analysis to the Eclipse&Maven users is now listed at the Eclipse Plugin Central.
You can visit EPIC, rate Q for Eclipse and leave your comments.
It should also be much easier for new users to get to know Q for Eclipse.
Well, not exactly. But now that you’re reading…
Issue MNG-3339 highlights one interesting maven feature: everything comes from the repository. This is usually fine, since you would like to depend on stable versions for your business, but it is not so useful when you’re developing a multi module project.
Say you have your typical webapp in maven. You might have a module for the model (myapp-model) another for the view (myapp-view) and so on. Obviously, myapp-view dependes on myapp-model. Every time you make a change to the model, you need to install it to your repository for maven to build myapp-view correctly.
Having the source code (and even compiled classes) in the same project is not (yet) used by maven to avoid that extra step of installing to the local repository.
Now, if you’re using an IDE, it doesn’t seem convenient to install the artifact after every change, since installing means running all the test cases, which can be lengthy.
Some workarounds exist on the IDE space, like using the IDE compiler instead of maven’s mojo. But this does not work on every case and, what’s worse, leads to different results when building from the IDE and from the command line. If you don’t install myapp-model, maven will fail to build myapp-view… but your IDE might succeed!
Because this is open source… why don’t you help in raising awareness of MNG-3339. Vote for it, comment on the issue if you have an opinion, watch it or do what would be the best of all options: attach a patch!
In 4 reasons it sucks to be in QA, Frank Kelly describes 4 causes that make QA… well, suck.
I initially felt surprised, almost happy: There are people out there that have a QA group on their company!
Leaving jokes aside, I will draw your attention to only a couple of things. Take a read of the full article if you want more.
So…. if the developers don’t like QA and the managers don’t follow QA advice… what happens? It is the user who finds the bugs in your software.
The solution to this, proposed by Frank, is to have developers and QA sit side-by-side and work together closely throughout the entirety of the software lifecycle
.
QA, after all, are playing the role of your end-users…. just in-house. They are much better than your prospective users at getting back to the developers. They won’t say “This is not working!“, they will explain, provide useful information and be available for contact.Without QA, Frank’s advice turns to “have the developers and users sit side-by-side“. But wait… that is pretty close to Agile methodologies’ evangelism.
I would certainly like that. Break the barrier between product development and product testing. On some cases, you could even break the barrier with the users. Involve them in the development cycle. Betas and prerelease versions might be ok.
Think of this… if QA is not respected by the developers/managers, then the same disrespect will be applied to users. Both QA and users find bugs, don’t they?
It’s been a while since Java Applets were introduced to the web. They didn’t catch a lot of interest for the mass-market. Neither did Flash for a long time… but now, things are changing incredibly fast.
Flex has been key to this, followed by similar solutions from Microsoft (with Silverlight) and Sun (with JavaFX).
The result is desktop-like user interfaces on top of web applications.
I know, this is nothing new. Has been happening a lot in the past year or so. But this is the first time I see something useful (don’t confuse with profitable with this) and impressing done with this techlogies.
Watch the video…
Yeah, you’re right. A suite of tools for graphic artists (well, there’s also a word processor for “writers and poets”)… right on the web. With 3D rendering and lots of bells and whistles.
Via TechCrunch.
I’ve just discovered Coding Horror (thanks to a link in Creating Passionate Users). It seems like it could become another of my favourite blogs.
Reading it, I landed at a post titled Error Codes Must Die and liked it, although I disagree with that because moderately complex software needs a way for “speaking” with the creatures that support it / use it… whichever language they speak. If you receive an error message in your native language and try to google for it (supposing your native language is not English), your chances of finding a solution are small (compare the results for this error in English and Spanish). Googling for the error code is always better.
Things might be different when the message is for a non-technical user and the user can actually do something about it. For example, appending an error code to a message like “There’s no space left to store the file, please choose another location” makes no sense. However, if that message were logged to a file as the result of internal operations and (maybe) translated to another language, the error code would make more sense.
All in all… although I like error codes, I think that error messages should follow the rules described on the article specially when displayed to the user:
Be Polite
Never forget that an error message box is the program reporting on its failure to do its job, and it is interrupting the user to do this. The error message box must be unfailingly polite. It must never even hint that the user caused this problem, because that is simply not true from the user’s perspective. The customer is always right.
The user is not expecting the error. In fact, the user expects nothing to fail. If the VCRs stills works (even when no one uses them nowadays), the microwave still heats anything inside… why should this high-tech, expensive computer running this expensive software fail?
Be Illuminating
The error message must illuminate the problem for the user. This means it must give him the kind of information he needs to make an appropriate determination to solve the program’s problem. It needs to make clear the scope of the problem, what the alternatives are, what the program will do as a default, and what information was lost, if any. The problem should treat this as a confession.
That’s something we (programmers, designers, QAs) tend to forget. The fact that we know or guess the internals of the software does not mean that the user will. NullPointerException is meaningless to the user (it is also usually meaningless for the developers alone).
Some times we try harder: The specified resource could not be allocated. What resource? Allocated where?
In general… include in the error message enough context, even if it is implicit by the code leading to the error, because the user will not read the code.
Be Helpful
It is wrong for the program to just dump the problem on the user’s lap and wipe its hands of the matter. It should directly offer to implement at least one suggested solution right there on the error message box. It should offer buttons that will take care of the problem in various ways. If a printer is missing, the message box should offer options for deferring the printout or selecting another printer.
This is my favourite.
If the person who designed / implemented the software does not know what it should do… how do we expect the user to know?
The decision should be, for the most part, on the software. The user should only need to make a simple decision, like deleting some files and saving again, or choosing another device.
On the other hand… if the designer / coder knows exactly what to do… then do it. I’ve seen applications with error messages in the line of “You can’t select that, it is already selected it, haven’t you noticed?” (actually, the message was way shorter and not so personal)
