Note that I do not necessarily endorse the articles or applications I link to. Most of the links to tools are here specifically because they seem interesting to me, but I have no actual experience with them—hence the need for a reminder on this list.
I have tried to group the links somewhat, but other than that they are listed in more or less random order.
Makefile.
This article was also discussed on Hacker News.README: gron transforms JSON into discrete assignments to make it easier to grep for what you want and see the absolute ‘path’ to it. It eases the exploration of APIs that return large blobs of JSON but have terrible documentation.
movie/series recommendation engineI use this site regularly to check if I can stream a movie or series in my country and if so, on which service it is available.
rsync based script to backup my Linux machines to an
external disk. If I go that route, I’ll also have to have a look at
restic-tools.My first observation: since I’ve been developing Plone sites for a couple of years now, I’m not really part of the targeted audience. The book is meant for people without Plone experience and the reader doesn’t need any programming or CMS knowledge.
As a result the book starts with an introduction to Plone (and Python) and guides the reader through the installation of an instance. While the unified installer is demonstrated, the book also shows buildout. The latter may seem unnecessary for the target audience, but later chapters also use buildout, for instance to install add-on products.
Chapters three through eight are devoted to core concepts of Plone: managing content, configuration, users, groups, workflow, security, and so on. These chapters give the reader a good overview of what Plone has to offer for intranets. The author also suggests a number of third party products to add even more functionality (see the table of contents for details).
Chapter ten is where the book surprised me a bit. Suddenly the author starts developing a product himself. This wasn’t exactly what I had suspected given the target audience. Chapter eleven switches back to using the available functionality (like content rules, WebDAV and external editing). Yet in chapter twelve there’s more code: subjects like TAL, METAL, viewlets, acquisition and resource registries are briefly explained.
The last chapter is devoted to deploying the intranet. It demonstrates Apache configurations, but also discusses the usage of a ZEO server/client setup, load balancing and caching.
It’s hard for me to put myself in the shoes of someone unknown with programming, Plone or even a CMS, so I might underestimate the target audience of this book. However, I feel that the chapters about creating a custom product and theme (chapters ten and twelve) might not be suitable for them and leave them with a lot of questions. On the other hand, the author has experience training non-technical end-users and so let’s give him the benefit of the doubt.
By the way, don’t let the fact that the book is based on Plone 3 scare you: the author frequently points out where it differs from Plone 4.
Overall Plone 3 Intranets is a good introduction and a really nice overview of the broad functionality Plone has to offer. After reading the book you should probably be able to get a nice intranet up and running with the practical tips and examples in the book.
]]>The book is written for Django application developers and requires basic knowledge of Python and Django. And although the code samples are indeed explained, the context is not always expanded on. This makes sense for this book and the author recommends to at least do the Django tutorial. I think you’ll get even more out of the book if you’ve got a bit more experience with building Django applications.
As the title already gives away, the book focusses on two subjects: testing and debugging. These topics are discussed while developing a survey application. Because this application is used consistently in the book, the examples require less explanation which means that the focus in more on the subject at hand (e.g. writing a unit test) instead of developing this specific application.
The first five chapters dive into the world of testing. Karen starts
with explaining how to run the tests and what success and failure
looks like. The second chapter has a focus on
doctests. Not only does
she show examples of tests, she also lists pros and cons of using
doctests. Meanwhile she also discusses whether a test is even useful
(example: you should not test Django itself). The examples in the book
consist of doctests that are placed in the docstring of functions. She
does not show how to run a doctest in a separate file
(e.g. README.txt) which can be more useful for explaining or
demonstrating the API of the application as a whole, or doing
integration tests.
Unit tests are
discusses more extensively in chapters three to five. Karen starts by
reimplementing the doctests as unit tests and continues by showing
things like the setUp and tearDown methods and also
django.test.Client to test views. In the last chapter about testing
she introduces the reader to test runners, test coverage and using
twill instead of
django.test.Client. The only thing I want to nag about is the style
of some of the examples. Occasionally she writes things like:
def testHome(self):
from django.core.urlresolvers import reverse
...
Where I would write:
from django.core.urlresolvers import reverse
def testHome(self):
...
In my opinion every programming book should pay attention to programming style. Although it does not have to be addressed explicitly, the style of the examples should be consistent and follow the appropriate coding standards/guides (like PEP8 for example which states that imports must be at the top of the file).
Anyway, on with the book review… The remainder of the book is about debugging and troubleshooting. Karen first describes the functionality Django offers to debug your application. For instance, the debug error pages are explained in detail. The style Karen chose for this part of the book resembles watching a programmer at work: a mistake is made and results in an error page, the error reported by Django is investigated to discover the cause of the problem and the code is fixed.
Next subject is how to find errors that are less obvious: Django does not show an error page, but the application does not work as it should. Initially some custom code is created to show the SQL queries involved in a view. Although this code is replaced by the Django Debug Toolbar later on, it is also used to show how to package the custom code for reuse. (Personally, I would have kept the custom query display section a bit shorter and skip the packaging altogether. It’s beyond the scope of the book and I think there are other resources that describe developing for reuse much better.) Karen does a great job describing the features offered by the Django Debug Toolbar. She also explains why using print statements is evil and using logging is good.
The next subject (chapter nine) is the Python debugger (pdb). Not only
is this chapter a thorough description of the debugger, there’s also a
number of pages devoted to
race conditions.
Although this is an important subject, I personally sometimes forget about it
when developing an application. So I think it’s great that it the subject is
brought up in this book!
Chapter ten (“When All Else Fails: Getting Outside Help”) is a nice description of what you should do when you encounter a problem in Django. Karen points the reader to the Django documentation (to confirm you are using the API as it was intended) and Django’s bug tracker (where you might already find a fix for your problem). She also gives clear instructions and tips on what to do when the problem isn’t already fixed or perhaps hasn’t even been reported yet.
The last chapter of the book is about moving your code to production and making it accessible for the world. It gives an example for the required WSGI script and the Apache configuration. Furthermore, it also describes debugging the production environment and load testing with Siege.
Finally Karen discusses the use of Apache and mod_wsgi during development. Although she claims that the Apache/mod_wsgi setup can be made nearly as convenient as using the Django development server I think it really depends on the situation. I agree that it may be a good way to tackle some problems and setup issues early on. But if you are working with a number of developers on the project and each developer is working on several different projects (sometimes even switching projects throughout the day), I’m not sure whether it’s worth the effort.
I’ve been developing in Python a couple of years, mainly working on Plone projects since 2007 and doing Django applications since 2009. I was already more than familiar with the topics in the book (doctests, unit test, logging, debugging, et cetera) and have also done a bit of test driven development. As a result, the book did not open a whole new world for me. However, I do think that the book was worth the read. I picked up a few new tricks and gained an even better insight in testing and debugging Django applications.
One last complaint though: the title of the book could have been a bit better: by putting the Django version number in the title, the book seems to target Django 1.1 specifically. Sure, Django 1.1 and 1.1.1 have been used in the book. And sure, some examples might not work in earlier or later versions of Django. However, the principles remain the same! In my opinion the version should have been left out of the title.
Although I may not agree with everything, I think Django 1.1 Testing and Debugging is a good book. So I’d like to thanks Karen and Packt for writing and publishing it.
]]>