Zope

Why does he care about telling us about design? He can't teach us design in half an hour. What he can do is tell us about the design that we can do something about. Design is just one of the things that you should know a little bit ... [More] about. Just like you must know a bit about databases, optimization, caching, deploying, testing and so on, you must know a bit about design. As programmer. Don Norman quote: attractive things work better. The goal is sucking less. You're not going to be a great designer. A good way of sucking less is doing less. Be minimal. You simply have less opportunities to suck. It is also a bit of a trend nowadays to do more with white space and to put less on a page. "Minimalist design". He showed some examples. Just a few colors. A solid background. A couple of 1px dashed lines to add structure. Create a visual hierarchy. Try to steer the visitor. Some things are more important, some are less important. Add contrast for that. Add discoverability. Put your content front and center. That's the most important part. Squint your eyes and look at your page: can you still make out the main content block? Also: give your content room to breath. So add white space between things. It helps set them off. Contrast (color, or bold, or upper/lowercase) helps showing your hierarchy. Emphasize (big, color) and de-emphasize (smaller and a bit grayer, for instance). Play with it. Steal ideas. Keep a folder with screenshots of (parts of) pages that you like. You'll get better with time. Design with a grid. You don't need a unique structure every time. You can use one of the available css frameworks, for instance http://960.gs/ or http://www.blueprint.org/. Such a grid seems to fit our brain and it almost automatically looks OK. Just go with a grid and start with pencil and paper. Typography is not only font selection. It also means laying out your letters on a page. There's loads of best-practices from our 574 years of typesetting, but most of that got forgotten when we moved to the web. There's more attention lately. Some things NOT to do: Lines are normally set "solid". Set a line height of 1.3em to 2.0em so that the lines are set a little bit apart. This is the biggest issue on most websites. Don't make the columns too wide (and thus the lines too long). Rule of thumb: make your line about two alphabets (a-z a-z) long. 12 pt fonts. That's ok for books, but a computer screen is further away, so 16pt is better. Too many fonts. Rule of thumb: just 2 or 3 typefaces, maximum. A good guide is a sans-serif ("helvetica") for titles and serif for body text (for instance Georgia). Two highly recommended links: http://typographyforlawyers.com and http://webtypography.net . Most browsers (including IE since version 4.0) allow web fonts. You can use more than those 8 standard fonts now. You can DIY (for instance with the FontSquirrel font-face generator) or you can go with a hosted solution like http://typekit.com/ (note that google also jumped into this lately with typekit so those fonts are now hosted using google's CDN). Color. Choosing a good color scheme. Color theory is hard, it is a lot like music theory. Watch out for localization as colors have different meanings: in the west, white means purity, in the east it often means death... If you don't know what to do, go with a monochromatic scheme. White/black plus red, medium red, light red. You can go with complementary (colors on the opposite sides of the color wheel) and many others. Two suggested sites for color schemes: http://colourlovers.com and http://kuler.adobe.com . Steal and learn. Look at http://patterntap.com/ or sites like that to get design ideas. And read a free book http://designingfortheweb.co.uk/book . Rules are meant to be broken. Just don't break too many at the same time. Question: stealing? What are the legal issues? Answer: I didn't mean steal steal, I meant lifting ideas. Don't copy someone's layout wholescale. Change things. Question: what about color blindness? Answer: hire an expect, this is hard. Colors are hard. There's biology, culture, ... [Less]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please note: First of all, apologies for the cross-posting. I wanted to reach as many people as possible. On Thursday, May 27 (2 days from now) one of the Zope Foundation-maintained servers will be ... [More] physically moved to a different data center by our hosting provider. The server will be shut down at around 20:00 UTC and, according to the hosting provider, become available again no later than 05:30 UTC the next day (Friday, May 28). This outage will affect several websites as well as the mailing list service. No mail sent to the lists will be lost, though, it will just be queued up on our secondary mail relay, which is unaffected by this move. Once the main server comes back up it will be delivered. Services affected ================= - the docs.zope.org website - the download.zope.org website - all zope.org mailing lists and the lists.zope.org website Server shutdown =============== Thursday, May 27 20:00 UTC - 22:00 CEST/Berlin - 16:00 EDT/New York - [Less]

Peter Bengtsson picked MongoDB out of the available NoSQL databases just as it seemed to be the best for his needs at the time. He had already 10 years of NoSQL experience: zope's ZODB object database (which stores python pickles). A ... [More] NoSQL database matters as it can be much more performant than an SQL database. MongoDB has some features that make it easier to step over from an SQL database. Internally it uses BSON (JSON + some binary types, for instance datetime). You can set it up in a master/slave configuration. A big thing about MongoDB is that it is document-oriented, so it isn't a simple key/value store and it also isn't a sql-like database with fixed columns. MongoDB has some implications: No joins. Your code suddenly needs to work with pagination. No transactions. You might need to change the way you code. You cannot rely on rolling back a transaction, so perhaps your views have to do smaller things. The speed advantage is huge, though, so it is also easier to write smaller changes more often. Polymorphism. It makes inheritance workable. Inheritance of structure (awesome, according to Peter). You can ask for all "Pages", but also for all "WikipediaPages" if that's a subclass. IDs are hashes, not integers. So you'll have to change your \d+ regexes in your urls.py. The Django admin is one of the things that initially stop working when you use MongoDB. Flatpages, piston, celery, etc. You can change things, though, to get them working again. The python bindings are explained in the API docs of pymongo. You probably also need one of the "ORM"s for python and MongoDB. See the ming ORM or an article by Peter about mongoengine and django-mongokit. Peter has a suggestion on what to use when starting with NoSQL: MongoEngine. It is the least verbose and it has automatic collection management. Django-mongoforms is nice for forms. Look at the Django non-rel project that released something nice just yesterday. So Peter warns that some of his talk might be overtaken by reality by that. So look it up! (About the photo: 1990 school trip to Berlin) [Less]

I've just finished reviewing Carlos de la Guadia's Grok 1.0 web development in the train on my way to Berlin for the EU Django conference :-) End verdict: solid book that explains everything you need to get going with Grok. Also valuable ... [More] as reminder when you're more advanced as it is handy to look up, for instance, how to best deploy your application or how to set up users and security. Next, I'll give my notes on a chapter-by-chapter basis, as that's the handiest way for me to give my feedback on the book. Chapter 1. Grok intro. Grok has three good things going for it: Zope's component architecture; the object database; object publishing and traversal. All three are explained. The Zope component architecture (ZCA) is, due to its brevity, hard to follow if you don't know the terms ("adapter", "utility") beforehand. Traversal: it just works. You can have an arbitrary hierarchy of objects and Grok will traverse them just fine. Packt's default layout (huge headers, also for "h3" headers) bites this chapter as page 12 just overflows with headers. Not the author's error, though :-) The comparison with ruby on rails and with Django are pretty much spot-on. Grok is heavily inspired by RoR's "don't repeat yourself" and "convention over configuration", but combines those with Zope's strong and clean component architecture. Django also likes those two RoR characteristics. Django is more focused on relational database back ends and wants to keep most major parts private (its own ORM, its own template language, etc) to keep Django's admin interface working. Grok doesn't provide such an admin interface, so it is more free to reuse, for instance, sqlalchemy. Chapter 2. Starting with Grok. Grokproject is a handy tool to generate a Grok project complete with a buildout environment. It is basically a well-tweaked wrapper around the Paster code generation tool. You get a working application right out of the box, ready for customization. Chapter 3. Views. As this is the first foray into customization land, some of Grok's conventions need explaining. Followed by a LONG explanation of Zope's TAL/TALES template language. Seemingly every Plone/Zope/Grok book needs one of those. Powerful template language and nicely integrated with html, unlike Django's curly braces stuff. The advantage of Django's curly braces stuff is that it needs less explaining and that it is less verbose than TAL's html/xml attributes. (I still really like TAL, btw). A good thing about TAL is that it is easy to put dummy data in a valid template so that you can see what you're doing. And so that you can already do some css. And you can build up a proper page and flesh out what data you're going to need from the code before even diving into python. That way, you get better code. The book does this, too. Chapter 4. Models. By default, Grok uses Zope's object database (ZODB). Which is a more natural fit for python objects than an sql database with an object-relation mapper (ORM) around it. The chapter nicely shows the advantages. Including the container mechanism with which you can build arbitrary hierarchies, should your data call for that (think content management system or intranet, for instance). Chapter 5. Forms. Every framework has a mechanism for generating forms from some schema. Grok does too and the book explains how, including a handy list of all available default schema types (choice field, URI, TextLine, etc). Chapter 6. The catalog. Or: the jackpot! If you use the zodb, you can add indexes to aid you in searching ALL your data. Full text search in all your various text fields, anyone? Pure luxury. This chapter shows how Grok helps you in setting it all up. Chapter 7. Security. Zope's and thus Grok's security mechanism is powerful. Per-object security out of the box instead of class-level security as offered by default by most other frameworks. It does mean that the chapter is a tad hard as there are a few layers of concepts to work through (users, principals, roles, policies). And some of it is defined in an xml configuration and some of it can be elegantly configured right in the code with Grok statements. The chapter also explains how to add a "pluggable authentication utility" that actually does the authentication and so. I've always wondered why one isn't already included in Grok: I'm so used to having one available from my Plone time... Anyway, the chapter explains how to set one up by hand. Chapter 8. Layout. Grok has a nice way to set up your templates: a lot can actually be handled in code. The template says to render a viewlet manager and the code takes care of registering small viewlets to those viewlet managers. That way the template doesn't have to bother about the number of menu items, for instance: it just renders the menu viewletmanager. Real handy to selectively inject something into the template from an object that actually knows best when something is needed. Nicer than Django that doesn't have something like that out of the box: you need to set something up yourself. Before getting to that viewlet stuff, the chapter explains how Grok looks up objects at all and how it renders views and templates after that. It came as a bit of a surprise to me to find it here. Perhaps it was the best place after all. Grok has an opinion about layout. Django (which I'm working with now) basically has no layout story: you need to set that up yourself. The assumption clearly is that you're better off setting it up yourself after all as sites' needs are wildly different. On the other extreme, Plone really has a layout story, coming with a ready-made layout and a big main template. Chapter 9. Grok and the ZODB. ZODB is that super-de-luxe easy-as-pie python object database, remember? This chapter explains the ZODB details like ACID, transactions, ZEO replication (really easy to set up replication of your database!), packing, etc. Good explanation. Chapter 10. Grok and relational databases. You didn't think Grok would leave relation databases in the cold, now would you? This chapter shows you how to tie sqlalchemy into your Grok project so that you can use sql objects as first-class Grok citizens. Chapter 11. Key concepts behind Grok. Grok uses all of Zope's component architecture. Interfaces, adapters, events, etc. All are explained in this chapter. Adapters are the things I miss most when developing with Django now. I'd really have to look into using it. You can use interfaces/adapters without pulling in the whole of Zope, so there's nothing really stopping me... I often have to render something on a map, so just calling for an adapter to IMapRenderable or so would be handier than registering stuff in setuptools entry points or in custom registries. BFG, another framework that uses some Zope machinery, advocates wrapping all the Zope machinery in a small number of custom api methods to hide the complexity (if I remember their docs correctly). That might be a nice idea to try out. Anyway, the chapter is very useful. A good intro on the various Zope concepts that Grok uses. Chapter 12. Grokkers. Hey, grok makes configuring your application and setting up the Zope machinery easy. No xml sit-ups. You can do that yourself, too! Build your own grokker. This chapter explains how. For those coming from the Django world: Django effectively does something similar with its model classes: there's a whole lot of setting-up going on behind the scenes when you add one extra field to your model class! For me, the chapter had a funny detail. As example, it set up a configuration mechanism for sending emails. That's the very same subject on which I worked on a grokker last year. This chapter sure would have been a great help to have had next to my keyboard then! Chapter 13. Testing and debugging. Not much to say here. Grokproject sets you up with a pretty good ready-made testing setup. The chapter shows you all the basics. Chapter 14. Deployment. Also not much to say here. Solid chapter. The hint to use mod_wsgi is a good one. And providing an explanation on how to set up zeo database replication is good. Setting it up is not hard, but you do need an example configuration. Again my end verdict: solid book! Recommended if you do grok development. [Less]

My shelf of review copies of Packt Publishing books is getting, well packed. But that’s OK, I enjoy reviewing books, and they look good. The latest addition is the Plone 3 Products Development Cookbook by Juan Pablo Giménez and Marcos F. Romero. To ... [More] my surprise this book is black and green, not Packt Publishings ordinary black and Orange. That probably won’t look as good in the shelf. I wondered how useful a cookbook could be, it’s after all a series of “recipes”, telling you how to do one specific thing, and often you need to do something slightly different, and then the book might not be so useful. Reading the book dispelled those worries. Some of the specific recipes in this cookbook are how to set up a development environment, and installing and using various Plone development tools. That’s always useful. The book then goes on to explain how to make content types, create workflows, do caching and portlets etc, covering the most important parts of Plone development. My major complaint with the book is that they focus the testing examples exclusively on doctests. Doctests are designed to test documentation. But there has been an unfortunate trend in the Zope and Plone world to do all testing as doctests, something which is evil in many ways. The book should come with a warning sticker: “Warning: Abuse of  doctests can be dangerous to your sanity”. Other than that, this book makes for a great entry book to Pone development, something that has been lacking in Packts set of Plone books. By the nature of the style of the book the recipes are sometimes lacking in depth, but they’ll get you 99% of the way there, which what entry books should do. It’s not a book for complete Plone newbies, you will need to know a bit of Plone first, for that I can heartily recommend “Practical Plone 3“. And no, I’m not paid by Packt Publishing to say that. They just send me the books for review, that’s all. Plone 3 Products Development Cookbook book will also work fine for Plone 4 development. How to develop in Plone hasn’t changed that much between Plone 3 and 4. That said I’m hoping for a Plone 4 edition that has changed most of those doctests to normal tests. Filed under: plone Tagged: book, packt, review [Less]

A Plone product that provides the PDF viewer FlexPaper.

Grok 1.1 released! ================== Grok 1.1 is a feature release of Grok preparing for the Zope Toolkit. The major user visible change is Python 2.6 support. Grok 1.1 supports Grok 2.6 and 2.5. Python 2.4 support is deprecated. Note that to ... [More] install Grok on Windows, please use Python 2.6, not Python 2.5. The other user visible change is a new version of the Grok UI. This now uses a more extensible UI framework, and cuts down on dependencies. You will also note that the Grok introspector has been removed - we did this to cut down on dependencies for Grok, but we are looking into ways to bring it back in the future. Other user visible changes are relatively minor: see Grok's `change log`_ for more. .. _`change log`: http://pypi.python.org/pypi/grok The main changes in Grok 1.1 are under the hood, however: * Grok builds on a prerelease version of the `Zope Toolkit`_. * New more reusable spin-off libraries Grok uses: grokcore.site, grokcore.annotation and grokcore.content. .. _`Zope Toolkit`: http:/ [Less]

Attracting and keeping talented developers is the lifeblood of any open source project. Domen Kožar is one such developer.  I met Domen at the 2009 Plone Conference and he showed me a thing or two about Vim that I didn’t know. He has already ... [More] contributed to a number of Plone related projects. As he is currently a student, he needs a little help from the community so he can attend the Sauna Sprint.  I am sure a lot of us can relate to the unique financial circumstances you find yourself in as a student.  You can read more about his request here. This community has come through in the past to help a fellow member. I am asking, for a minimum donation of the cost of a beer in your country, help Domen get to the sprint. Let’s make this happen. [Less]

Grok 1.1 is a feature release of Grok preparing for the Zope Toolkit. The major user visible changes are Python 2.6 support and new version of the Grok UI. The main changes in Grok 1.1 are under the hood: now Grok builds on a prerelease version of ... [More] the Zope Toolkit. Grok 1.1 should be compatible with Grok 1.0. Grok 1.1 lets you prepare for the upcoming Grok 1.2 release by updating your imports. For more information about this release, see the release info: http://grok.zope.org/project/releases/1.1 [Less]