Exjali - EXpressiveness JAva LIbrary

Inspired by the buzz around Java 7 and "new" JVM language (Groovy, JRuby, Scala, ...), Exjali is a small Java librairy, allowing more expressive statements without altering the language. Exjali includes some attempts for ranges of integers, SQL-like functions, IO facilities, functors and named parameters.

Exjali

Blogged with the Flock Browser

foxit supports inline viewing of pdf in firefox...

Firefox SupportWith Firefox Plugin, users can view and work with PDF files loaded in Foxit Reader with Firefox web browser.

Featured Windows Download: Foxit Reader Updates, Supports Inline Viewing in Firefox

jetty

Jetty is an open-source, standards-based, full-featured web server

jetty - Jetty WebServer

kan vera alternativ til tomcat, td i lag med jboss.

elles: juster parameter i webdefault.xml, useFileMappedBuffer, til å vera false for å unngå låsing av jsp- og css-filer.

Files locked on Windows

automatic testing - challenges

"practice of testing .... turned our art into engineering, introduced process-models, come up with best-practices, and developed tools ..."

Google Testing Blog: Automating tests vs. test-automation

downsides, problemer:

• "Scripting your manual tests this way takes far longer than just executing them manually.
• The UI is one of the least stable interfaces of any system, so we can start automating quite late in the development phase.
• Maintenance of the tests takes a significant amount of time.
• Execution is slow, and sometimes cumbersome.
• Tests become flaky.
• Tests break for the wrong reasons."

men: "advantages of automation still outweigh the cost. .... accept some of these problems as 'the price of automation'"

og der er workarounds:

• "It takes long to automate a test—Well, let's automate only tests that are important, and will be executed again and again in regression testing.
• Execution might be slow, but it is still faster than manual testing.
• Tests cannot break for the wrong reason—When they break we found a bug."

nokre poeng frå artikkelen (mi utheving):

"...a system exposes different interfaces to the environment—e.g., the user-interface, an interface between front-end and back-end, an interface to a data-store, and interfaces to other systems—it is obvious that we need to look at each and every interface and test it. ... also avoid testing the functionality in too many different places."

"...how this system looks inside.

• Is there a database? If so, the verification should probably not be performed against the UI but against the database.
• Do we need to interface with a supplier? If so, how should this interaction look?
• Is the same functionality available via an API? If so, it should be tested through the API, and the UI should just be checked to interact with the API correctly."

"Applying these simple questions will allow us to:

• write many more tests through the API, e.g., to cover many boundary conditions, ....
  
• start earlier with testing the system, as we can test each interface when it becomes 'quasi-stable',
• makes maintenance of tests and debugging easier, as the tests break closer to the source of the problem, ...."

"To summarize, I figured out that a successful automation project needs:

• to take the internal details and exposed interface of the system under test into account,
• to have many fast tests for each interface (including the UI),
• to verify the functionality at the lowest possible level,
  
• to have a set of end-to-end tests,
• to start at the same time as development,
• to overcome traditional boundaries between development and testing (spatial, organizational and process boundaries), and
  
• to use the same tools as the development team."

It's common sense, stupid: Tips to Write a Good Bug Report

Writing is easy, but writing clearly is hard.

It's common sense, stupid: Tips to Write a Good Bug Report

Do's

1. Clear title - the developer should be able to grasp the essence of the bug report from the title alone.

2. One bug per report - no more, no less. reason: confusion, duplication, may be overlooked.

3. Minimum, quantifiable steps to reproduce the problem

4. Expected and observed results

5. which version of the software

6. references - like related issues

7. Pictures-- A picture is worth a thousand words!

Dont's

1. Don't write generic titles
2. Don't just chat - document personal communications, so that the knowledge won't be lost
3. Don't assume that the developers can read your mind

software projects: have your cake and eat it?

in my opinion you actually can't; you're not able to make sure that a project is on budget, on time, and have all the planned features with high quality. there's always a risk, and you can only control any 2 out of the 3 factors at the most.

software projects: have your cake and eat it? - ingvald

frå artikkelen eg har lest:

"the only true measure of progress on a software development project is the delivery of working software. "
....
"potentially-shippable software at the end of each iteration"

dette medfører forsåvidt helst iterasjonar på ein mnd eller kortare...

og ein liten provokasjon - du bør ikkje prøva å måla framgang ift planen du har laga...

"... instead of measuring progress against your plan, ... you should instead be focusing on ensuring ROI and product quality. "