Skip to content

Companies

Good Project, Bad Project

Ative at Work - Wed, 08/11/2010 - 13:42
The secret to writing good automated tests is to be a good software designer.

It sounds trivial - but the sad fact is that more often than not the attempt to implement test automation falls due to poor software design where people are struggling with strong dependencies where you cannot test a single class or module without also configuring a whole environment of databases, webservices, populating whatever tables etc.

When the novice experiences this the natural, but incorrect reaction, is to write fewer and fewer tests at a higher and higher level of integration, the limit case being manual end-to-end integration testing through the GUI.

It is a symptom of bad software design, not automated testing being worthless.

In a good project the test suite does not need to be changed when external data changes. In a bad project, the test suite breaks when time passes or every time someone runs the end-of-month job to add interest to the accounts, or when the ticker price changes for a stock.

In a good project, only a few localized changes to tests and production code are needed as for a requirement change. In a bad project, there is impact analysis and lots of similar changes all over the code-base to accomplish this.

In a good project most of the code does not know from where it gets its data - in a bad project, even a simple interest calculation business rule knows about how to look up the database and the interest rate web service.

In a good project there is typically 1-2x as much test code as production code. In a bad project there is often 5x-25x as much production code as test code.

In a good project most tests exercise only a single class or a few functions. In a bad project every tests activates a code-path through many parts and tiers of the application.

In a good project most of the test code is asserting that things went as expected. In a bad project, most of the test code is setting up the environment to run the test.

In a good project there are tests at all levels of the application. In a bad project they are mostly through the UI and often even manual.

In a good project you can change the application without risk. In a bad project change is painful, infrequent, risky and requires executive sign-off.

In a good project you can deploy new code to production safely many times a day. In a bad project you only do it reluctantly every monthly or a few times a year.
Categories: Companies

Tweetable Code - Introducing Docjure for Succintly Reading and Writing Spreadsheets

Ative at Work - Fri, 07/30/2010 - 16:08

How would you like to be able to SMS or tweet your Excel data-crunching code?

With Docjure, it is possible:

(->> (load-workbook "spreadsheet.xlsx")
     (select-sheet "Price List")
     (select-columns {:A :name, :B :price}))

This reads the A and B columns from the Price List sheet in the spreadsheet.xlsx file into a list of maps where the a column has key :name and the B column has key :price.

I believe that is pretty good for code small enough to fit in an SMS.

Exporting your business data to spreadsheets for further analysis is just as easy:

;; Create a spreadsheet and save it
(let [wb (create-workbook "Price List"
                          [["Name" "Price"]
                           ["Foo Widget" 100]
                           ["Bar Widget" 200]])
      sheet (select-sheet "Price List" wb)
      header-row (first (row-seq sheet))]
  (do
    (set-row-style! header-row (create-cell-style! wb {:background :yellow,
                                                       :font {:bold true}}))
    (save-workbook! "spreadsheet.xlsx" wb)))

In just a few lines of code and you have exported the price list to a worksheet, complete with a yellow-background bold header line for extra style points.

In our business applications, bridging to Excel has provided huge benefits:

  • Users love it - having their data in Excel enables them to do much more than a static report that can only be changed by a software developer.
  • Developers love it - It eliminates a lot of tedious code for generating bespoke reports as we can easily export data into an Excel report template.
  • Project managers love it - using spreadsheets provides an easy to understand data exchange format and the flexibility to change reporting features quickly late in the project.
  • Sponsors love it - the project saves a lot of time and reduces training cost by leveraging an application the users already know.

As an inspiration, here are some of the things we have used it for:

  • Use Excel to calculate currency trading strategies - the traders calculate their currency trading strategies in Excel then import it into the trading system. They benefit from the flexibility of a powerful tool they already know and the trading system takes care of the technical details of the actual trades.
  • Exporting to Excel for bespoke analysis - would you like to check your currency trading record? Export all the information to Excel and the traders can slice-and-dice it easily with little or no technical assitance. This is much easier than setting up a reporting database for them to link to.
  • Using Excel sheets for content management to facilitate translation - translating an application to all the languages of an international enterprise was easy. Rather than using complex technical XML-files we made Excel sheets the data format for the application strings and had the subsidiaries add their translations to that. Then we put an adapter on the application to convert back and forth to XML-config files and RESX files used internally in the web and Silverlight parts of the application. The translators had a great experience, they had a familiar tool with spell checking and it reduced waste in the translation process by presenting a well-known easily accessible format.
  • Exporting to Excel for reporting - set up a spreadsheet template with a data sheet and some reports based on that, then populate it with data from your application. This allows the users to easily change or add reports with no change to the software application itself, thus dramatically reducing the turn-around time for new reports. 

We believe this is so great that we just have to share it:

Therefore, Docjure is free and open-source.

It is written in Clojure for the JVM. Get it at our GitHub page here: http://github.com/ative/docjure and be sure to follow our updates on Twitter: @ativedk (http://twitter.com/ativedk)

Categories: Companies

Psst...Scrumy has an API now

Scrumy Blog - Thu, 07/01/2010 - 07:00

It's a new month, and now there is a new Scrumy feature for Pro users: The Scrumy API. Pretty much anyone who has asked us if we have an API recently has already been directed to that page and has been able to access it, but now we're sharing our secrets with the world.

For the uninitiated, an API is an interface that we give to you in order to access the data that we've stored for you in a convenient way. Essentially, it allows you to write your own programs that interact with your Scrumy projects. If, for example, you wanted a big red button that moves all your unfinished tasks into the 'Done' column, you could build that yourself with a few clever API calls.

The Scrumy API is divided into two separate parts: REST and Webhooks.

The REST API allows you to get data from your projects in XML or JSON form using simple URLs. You can also manipulate your data by POSTing or PUTing data to those URLs. You can read all about it at the REST API documentation page.

Webhooks are very different. A Webhook is a URL for an application that you have running on your own server which receives data from us. This means that any time you create or change a task, for example, we will send a piece of data representing the change on your project to that URL. A simple thing you could do with this would be to send a tweet any time you finish a task. Read more at the Webhooks documentation page. Also, the demo is set up to use webhooks, but it works a bit differently than your projects. The demo will allow you to enter 5 webhooks, but none of them will be active for more than 5 minutes. So, if you just want to see how webhooks work, feel free to use the demo, but unless you want to be a jerk, use an empty slot. Then you have 5 minutes to test your heart out.

So those are the big updates for now. If you find errors while reading the apidocs or feel that you could clarify something, feel free to update the documentation. It's a wiki for a reason. If you have any other questions or comments, feel free to contact us at support@scrumy.com.

Categories: Companies