Developer Testing

Henrik Warne's blog

I recently found out about the book Developer Testing – Building Quality Into Software by Alexander Tarlinder, and I immediately wanted to read it. Even though I am a developer at heart, I have always been interested in software testing (I even worked as a tester for two years).

I think the subject of the book, developer testing, is timely. There seems to be a broad trend where more and more responsibility for testing is given to developers. It follows from the move towards micro services, dev ops and the “you built it, you run it” principle. Another driving force is the prevalence of developer testing frameworks that started with JUnit and now includes many more. These frameworks encourage and help developers write automatic tests.

Despite this trend of increasing developer testing, my feeling is that many developers still don’t test their programs well enough. For example, they may…

View original post 1,010 more words

Developer Testing

Caffeine :: Livecode the Web!


CaffeineFor the impatient… here it is.

Back to the Future, Again

With the arrival of Bert Freudenberg’s SqueakJS, it was finally time for me to revisit the weird and wonderful world of JavaScript and web development. My previous experiences with it, in my consulting work, were marked by awkward development tools, chaotic frameworks, and scattered documentation. Since I ultimately rely on debuggers to make sense of things, my first question when evaluating a development environment is “What is debugging like?”

Since I’m a livecoder, I want my debugger to run in the web browser I’m using to view the site I’m debugging. The best in-browser debugger I’ve found, Chrome DevTools (CDT), is decent if you’re used to a command-line interface, but lacking as a GUI. With Smalltalk, I can open new windows to inspect objects, and keep them around as those objects evolve. CDT…

View original post 626 more words

Caffeine :: Livecode the Web!

Is Software Engineering Possible?

A Programmers Place

When the textile industry arose in the 18th century, craft was the norm in manufacturing. As the industrial revolution progressed, one after another sector of the economy made the transition from craft to industry. In 1968 it was noticed that the creation of software was a craft in a world where industry was the norm. In that year a conference was convened to address that anomaly. Those present saw themselves as participants in a momentous occasion: after this conference, Software Engineering existed, which was not the case before.

In the final paragraph of my 2009 article “Software Engineering: From Craft to Industry?” [8], I ventured to disagree. From the final paragraph:

While the processing of material leaves an irreducible residue of work for humans, in the processing of information any work that is routine instantly vanishes. Extracting the routine part from an information processing task is a creative…

View original post 1,730 more words

Is Software Engineering Possible?

Lisp, Smalltalk, and the Power of Symmetry

In Search of Secrets

Like many hackers, my first real programming language love was Lisp. Paul Graham, who inspired my own explorations of the language, is a particular advocate and has written quite a bit about Lisp and what makes it different from other programming languages. So what does make Lisp different? Why does Lisp continue to be one of the most powerful, flexible, and concise programming languages in existence, despite the fact that it was invented in 1958–making it the second-oldest high-level programming language in the world?

View original post 948 more words

Lisp, Smalltalk, and the Power of Symmetry

Understanding deep learning requires re-thinking generalization

the morning paper

Understanding deep learning requires re-thinking generalization Zhang et al., ICLR’17

This paper has a wonderful combination of properties: the results are easy to understand, somewhat surprising, and then leave you pondering over what it all might mean for a long while afterwards!

The question the authors set out to answer was this:

What is it that distinguishes neural networks that generalize well from those that don’t? A satisfying answer to this question would not only help to make neural networks more interpretable, but it might also lead to more principled and reliable model architecture design.

By “generalize well,” the authors simply mean “what causes a network that performs well on training data to also perform well on the (held out) test data?” (As opposed to transfer learning, which involves applying the trained network to a related but different problem). If you think about that for a moment, the question pretty…

View original post 1,372 more words

Understanding deep learning requires re-thinking generalization

I tried Haskell for 5 years and here’s how it was

Meta Rabbit

One blogpost style which I find almost completely useless is “I tried Programming Language X for 5 days and here’s how it was.” Most of the time, the first impression is superficial discussing syntax and whether you could get Hello World to run.

This blogpost is I tried Haskell for 5 years and here’s how it was.

In the last few years, I have been (with others) developing ngless, a domain specific language and interpreter for next-generation sequencing. For partly accidental reasons, the interpreter is written in Haskell. Even though I kept using other languages (most Python and C++), I have now used Haskell quite extensively for a serious, medium-sized project (11,270 lines of code). Here are some scattered notes on Haskell:

There is a learning curve

Haskell is a different type of language. It takes a while to fully get used to it if you’re coming from…

View original post 984 more words

I tried Haskell for 5 years and here’s how it was