reMarkable e-Ink Tablet Review

I’ve long fantasized about an e-Ink tablet: something I could use for writing, sketching, and reading. The battery life, the “flat” appearance, etc all seemed perfect. Up until now I’ve settled for a Kindle for reading, chaffing against the Amazon ecosystem. I periodically look for Arduino or Raspberry Pi compatible e-ink displays (larger than 4”) that I might be able to hack into something larger, but always come to the conclusion that I don’t have the bandwidth for a project of that size. Back in December I came across the reMarkable, which promised a “paper-like” e-ink experience. No app store, no browser, just a pad of paper and document viewer.

My reMarkable arrived a few weeks ago, and I’ve been carrying it with me to work and to coffee shops since. Overall I’m impressed with the hardware and the writing experience. I suppose this shouldn’t be a surprise given their stated goal: a paper tablet. But I am surprised: the latency of the stylus and tactile feel against the “canvas” display is excellent. It’s by far my favorite part of the reMarkable experience.

Even though I pre-ordered, I was skeptical of how low the latency of a stylus on e-Ink could be. That bar was further raised when I started using an iPad Pro with the Apple Pencil for drawing. After using the reMarkable for a few days to journal, take notes, and doodle, it was clear that it’s a completely different animal than the iPad + Pencil. The friction between the tablet and the stylus brings a tactile feel to writing that a glass display just doesn’t have. Quite simply, the reMarkable team has done a better job transposing the paper experience to something electronic than I expected.

So if I was skeptical and still pre-ordered, why? I assumed that even if (when) the writing/drawing experience fell short, I’d still have a “big Kindle”, something of a dream. I had been reading more on my iPad when I ordered, and while I liked the bigger display, I wished it was e-ink display. Turns out my expectations were completely wrong: as good as the writing experience is, the ePub reading experience is bad.

Specifically, the ePub reading experience is bad. It’s slow to render, and frequently skips pages, mis-renders them, or gets stuck with strange page or column breaks. It’s simply not usable with ePub documents at this point. The reMarkable does much better with PDFs: in my experience thus far they render accurately and reliably, and it’s easy/natural to make notes or annotate them.

I think this reveals the reMarkable’s strength and technical approach: it’s a hardware PDF reader and annotation device. And in that capacity it’s very good.

Luckily the hardware feels more mature than the software package. I have found that the three buttons — previous, home, next — aren’t positioned great for writing full pages: my palm occasionally presses one, jumping me to the next page. I’ve taken to rotating it 180 degrees while writing to keep the buttons out of the way. It’s also not clear to me what sort of life I should expect from the stylus nibs: they’re clearly replaceable, as the device comes with 10 replacements. After I’d used the reMarkable daily for a couple of weeks I found the digitizer had started missing strokes on occasion. As an experiment I replaced the nib, and the problem went away. I’m going to stretch this second one as far as I can to see what sort of life I can expect.

Finally, the reMarkable has the best free software compliance of any hardware device I’ve seen: the settings dialog clearly lists every piece of open source software used, along with its license. Because some of the software is GPLv3 licensed, they also provide root access to the device over SSH. Poking around it appears that it’s running a QT Embedded application on Linux. I’m planning to try some other experiments when I have a moment (can I write a piece of software that uses the e-ink via frame buffer?).

Overall the reMarkable has been a fun device to play with. It’s replaced my paper journal for the last three weeks, and I’m experimenting with how it might replace other paper that remains in my life. I haven’t quite figured out how it complements or meshes with my iPad Pro, but it definitely doesn’t replace it: the Pro is (ironically?) a much more general purpose computer than the reMarkable.

Read: “Django 1.1 Testing and Debugging”, by Karen M. Tracey

Packt Publishing sent me a copy of `Django 1.1 Testing and Debugging <>`_ for review. I was particularly interested in reading this title, as testing is something I know makes my code better, but don’t feel like I do enough of, and because I work on a couple of Django-based projects in my spare time, with varying degrees of test coverage. While I consider myself comfortable with Python’s stock `unittest <>`_ and `doctest <>`_ modules, I was curious to learn about how you can integrate Django with other Python testing tools.

Django 1.1. Testing and Debugging is split, as the title implies, into two halves: Testing, followed by Debugging. It uses a narrative approach, following the development of a survey application throughout. The book starts with an overview of the stock unittest and doctest facilities in Python. Most of chapters 1 through 3 are devoted to the basics of unit testing, specifically for Model classes. Tracey provides information about Django-specific nuances along with way. For example, I didn’t realize Django ships with a customized doctest module to enabled ELLIPSES support in Python 2.3. Chapter 3 also provides information about how to use fixtures for providing test data, and how to specify those apart from the initial data fixtures developers may already be aware of. Chapter 4 mirrors some of the information found in Django’s testing documentation: the Django TestCase, and how you use it to do basic view testing.

Chapter 5 describes integrating Django with other tools, primarily by example. Tracey discusses how to replace the default Django test runner, and what interface the replacement needs to implement. She also provides a stub example of more “invasive” integration, crafting a new management command that could (possibly) handle code coverage reporting while running the tests. This stub was interesting, but didn’t feel particularly testing related to me. Chapter 5 closes with examples of using the excellent coverage package with django-coverage, and integrating twill into Django tests.

Chapter 6 begins the section on debugging with an overview of the Django settings that impact debugging, and how the development server supports debugging of applications. Chapter 7 follows with a thorough analysis of the development server’s error page, as well as examples of debugging based on the information given. The examples continue to develop the survey application, and introduces what Tracey describes as “typical mistakes”, then describes how to fix them.

Chapter 8 begins to dig a little deeper, and I was happy to see mention of Rob Hudson’s Django Debug Toolbar, an indispensable tool. Chapter 8 also includes details on using the logging module, and how to develop a decorator that marks function entry and exit. I know that I’m all too guilty of using print instead of logging, and it was nice to be reminded of how easy this is.

Chapter 9 was my favorite part of the book. It gives a good overview of using pdb, and then goes on to demonstrate how to use pdb and a shell session to test a race condition and deal with it.

Overall `Django 1.1 Testing and Debugging <>`_ seems like a good introductory book for Django developers who are new to testing (or Django). While many of the debugging examples seemed obvious to me, I suspect that someone new to Django could use this book as an introduction to development and debugging.

date:2010-06-06 17:42:47
tags:2010, nonfiction, read, review

Read: “Grok 1.0 Web Development”, by Carlos de la Guardia

A month and a half ago I posted a pre-review of `Grok 1.0 Web Development <>`_, a new title from Packt Publishing (disclosure: I received a complimentary copy of the book for review). I recently completed a spate of travel that took me across the Atlantic and across North America (with another trip across the Atlantic aborted due to the volcanic ash cloud), and have turned my attention back to the book. My initial impression remains: this is exactly the sort of documentation I wish I’d had when I ported the Creative Commons license chooser from “pure” Zope 3 to Grok. Grok 1.0 Web Development is a great introduction to Grok, Python web development, and the Zope Component Architecture.

|image0|`Grok 1.0 Web Development <>`_ takes what as I think of as a customary approach to framework introductions, instructing the user on the basic features of the framework by building an application (in this case a to do list manager) and adding features and refining the code as it goes. This works well for Grok — the amount of boilerplate code is kept to a minimum, by design, so the text can focus on first implementing the feature, then delving deeper to discuss the “best practice” around that tool if needed. For example, Chapter 6 covers ZODB Catalogs (index). It starts by defining the search view and user interface so that the reader has a functioning search tool to work with, then takes a diversion to discuss how one best structures their application to support search. These detailed drill downs are one of the most valuable parts of Grok 1.0 Web Development: they help the reader expand their understand beyond just implementing a feature, to implementing in a way that will be flexible and easy to support in the future. The [somewhat brief] advice on when to use the ZODB versus a relational database is another example of practical advice that I appreciated in the book.

Grok 1.0 Web Development is not perfect. In particular I wish the chapter on testing were earlier (the author’s admonition that it “should not be treated as an afterthought” doesn’t seem to jibe with its placement among the advanced topics towards the end of the book. I suppose I’m also a little sensitive to slogging on Zope 3 and it’s “lack” of agility. I can probably be described as a Zope 3 / Zope component architecture apologist, but it seems the type of agility described is a rather narrow, specific definition. The sprints I did on Zope 3 at PyCon several years contributed more to my understanding and appreciation of test driven development and agile planning than just about anything. Yes, Grok gets it done without the ZCML; I think it’s an exercise for the reader as to whether that’s better or worse for your application.

I think that the Zope derived frameworks such as Grok and repoze.bfg are some of the most interesting in development today. Grok 1.0 Web Development does a great job of introducing Grok to developers who are new to web programming, or who already have some familiarity with another framework. I recommend it to anyone interested in building extensible web applications with a minimum of boilerplate.

date:2010-05-02 15:36:19
tags:2010, nonfiction, read, review