To aid in linguistic understanding and to further world peace, I've been compiling a helpful dictionary. The start of a new year seems a good time to share, before we are overwhelmed with a new crop of jargon.
Virtual: On a computer.
The cloud: On someone else's computer, trusted implicitly for your security and privacy.
Platform as a service: On the internet.
Web 2.0: A method of refreshing advertisements without reloading the entire web page.
It shines with a brilliance we did not expect, attracting our attention. Though we can't discern shape or colour, it's impossible to look away. This is the cynosure.
It's that very experience of being-in-the-world that "Lenore" explores. It's also the experience of watching this performance unfold.
Quite a number of people have asked me about the new Tascam DR-100 mkIII recorder. I have not used this unit, so the following analysis is based on the reference manual and promotional material.
Tascam have released a large number of digital audio recorders, but like many companies has not been addressing the needs of the field recordist. Their strength has been in tools for musicians, so their recorders have been oriented towards recording practice sessions or live performance. Low pre-amp noise is not a priority in these cases, and their previous units have had middling sound quality and spotty feature sets.
The same is true of the 60D and 70D models, designed for DSLR video shooters. These are feature rich but far to cheap to contain decent components. The pre-amps are OK for their designed purpose, but in my experience are intolerant of the different impedance loading scenarios that professional microphones might bring.
While I haven't used the 701D it appears to share the same innards as the 60D/70D. And then there's the revised 60D MkII... good grief not another model! According to the company's own literature the pres have been "improved" to be like the 40D, which are poor.
So, Tascam has so far not produced a smaller recorder sufficient for nature recording. How does the new unit measure up?
I have been creating websites for almost as long as there has been a web. For many years I was CTO of a business that did things then thought impossible (namely, large data transfers and processing). For two years I wrote Perl scripts. I have many hours of server configuration in my distant past, now thankfully (mostly) forgotten.
I now require a simple, open, extensible, standards-based solution. I am technically capable and don't mind programming a solution. But any coding must be in Python, since other languages waste my time. (I trust that is partisan enough!)
I will now summarise five different website development methods, as I see them.
The downsides of this method soon become apparent: maintenance, repetition, and sheer drudgery.
2. Generated static
Desktop tools can automate some or all of the process. Templates can be used to provide a basic pattern for a set of web pages. Specific data then fills out each instance. Code modules can be added to provide extra functionality. But the end result is still a set of static HTML files that can be viewed from anywhere.
Back when there were few available solutions I wrote my own programme, Wasp. This app worked in two modes, one of which was generated static files. And I have been using it ever since!
3. Dynamic server, fixed structure
This includes blogging sites like Blogger and most "easy" web front-ends. Content is delivered from a web server using CGI, but the process is completely hidden. The user is responsible for the content, and can modify the visuals to a degree.
This blog is one example. It is written on Blogger, which makes the basic process of posting articles quite easy. But the customisations you see here are the result of many hours of hacking and deciphering secret tech. When I dive into the code now, I have no idea what is going on.
A bigger issue is that the solution is closed. When (not "if") the Blogger engine disappear, my site disappears... and migration may not be an option. The knowledge learnt in one proprietary system is not transferable to another. They are a poor investment.
4. Dynamic server, dynamic structure
This category includes Content Management Systems (CMS), which range from the simple and cheap (Wordpress) to the complicated and terribly expensive (many corporate solutions). These provide a great deal of control over the structure and look of your website, and also easy methods to enter content.
This flexibility requires an increased commitment of time and effort. The same comments as above regarding the proprietary nature apply.
It's a given that a CMS option places constraints on server requirements and is often associated with increased monthly costs. It also restricts the choice of hosts. But these days the most popular solutions are supported by a variety of vendors.
I have developed client sites in Textpattern, which is open and free. Years later, these sites are still functional, but eventually will fade. All sites require maintenance as the underlying software versions change.
A CMS is a complicated beast. If you are building sites for a living, the investment you make in learning one might well pay off. Your customisations will be re-used often enough to be worth the time it takes to develop them.
But this isn't the case if you're using a system only occasionally. You will never remember all the little techniques and "gotchas". (That's why there's a thriving industry of Wordpress consultants.)
5. Dynamic framework
These code skeletons provide hooks into the web server and some useful scaffolding. They incorporate a CGI interface, so that dynamic websites can be served from Apache and the like. They assume that you have considerable programming skills, since you will be coding your own website structure and functionality.
My own Wasp was a workable solution. But it was made in an era when standard interfaces like WSGI did not even exist. It is out-dated and inferior to contemporary tools.
I spent a good deal of time evaluating the Python-based CMS solutions, but I am only going to present a summary here. The complexity of these systems, each with their own terminologies and assumptions, makes any comparison time-consuming and potentially error-prone.
The biggest issue is the amount of commitment necessary to properly review a product. Something simple and flexible at first glance may turn out to have hidden limitations.
We can break a CMS down to three areas of functionality: the templating system, data layer, and coding framework.
I am picky about templating. Certain products, typified by CherryPy, use "Pythonic" templating. What this means is that you mix in your code with your HTML template. To me this is a bad idea. Anything in a template should look like HTML (or meta-HTML). The Python code should stay in the code engine. This is doubly true in team development, where one expects a division of labour between the designer and programmer.
However, pragmatics comes into play. Sometimes it is easier to put logic in the template. A good solution will not require this but will support it.
Luckily, the situation in the last few years has stabilised and it seems that Jinja is the winner. This clear and powerful templating language is used in all of the CMS that made my final cut. The same was not true even a year ago, so be wary of reviews on the internet that are stale.
When it comes to the data, some products (eg. Django) bundle in an Object Relational Mapper (ORM), which is a way of translating from object-oriented code to set-oriented information in a database. My experience with these has been tainted, since they are terribly inefficient for large data sets. But for a website I am sure they are just fine. Nonetheless, I prefer that simpler options are also available.
Some coding frameworks are massive and bundle in as much functionality as possible (Django). Others are minimal and expect the developer to fill in the rest (Flask, Pyramid). I prefer the latter approach, since I won't be trapped by pre-made decisions.
This is true even if there is a rich ecosystem of developed plugins. There are several problems with using a plugin to add functionality. First, the plugin architecture itself my be restrictive or require excessive cognitive overhead. Second, you have just added a point of weakness, especially when it comes to security (Wordpress, cough). Third, you now rely on the plugin developer for timely updates as the main system evolves.
I will spare you further details of the forty or so systems I investigated. For me, Flask would be the system I'd choose when developing a dynamic website. But I'd keep an eye on Pyramid as well.
For a personal site, do I need dynamic content? Well, what does it have to do? (Have a look.)
I need to display a snazzy home page incorporating a couple hundred informative entries on my various activities. I want to filter these articles by category and show related articles for each, based on tags. The articles need to be sorted in reverse chronology, like a blog. And I will be adding more all the time.
So, yes, it does at first seem like dynamic content is needed.
What is needed is a darned good static site generator.
So I wrote one.
(To be continued.)
Adam Curtis is a neoconservative documentary film-maker funded exhaustively by the BBC. "HyperNormalisation" (view here) is his latest product, a sprawling collage of thoughts about contemporary political power. It displays his usual hallmarks: a totalising and reductive view of complexity, a disparaging view of artists, a dismissal of women that is essentially sexist, and an ignorance of philosophical thought, stemming from an inherent anti-intellectualism and self-aggrandizement.
His works are heralded without much criticism. This article will act as partial corrective.
The big problem has always been supporting the variety of software platforms in use. It's a significant challenge creating a unified experience for users of different web browsers on different operating systems. The recent proliferation of hand-held devices has increased the number of software platforms (Android, iOS), the number of rendering engines, and the variety of screen sizes in use.
In addition, the principle of responsive design holds that one single code-base should suffice for all viewer implementations.
That is why I am using Bootstrap, and specifically the new version 4 release of this platform. (Though this is still in alpha, I don't want to dedicate time to version 3, knowing the structure is imminently to change.)
Though the internal docs are good, there isn't much third party documentation on Bootstrap 4. I've been experimenting with layout and this article is the result.
I am proud to say I am a part of the new Silent Records. Founded by Kim Cascone (AKA Heavenly Music Corporation) in 1986, this label went on to become the seminal American ambient label. Well, Kim has rebooted Silent and released two giant compilations.
OK, so there's always the programmatic approach. And for that I turn to Python. Let's see what the state of the art holds for us. (Hint: It's a bumpy ride.)
Photography is all about the light. Without light an image cannot be captured. And it is often the quality of the light that makes a photo, in the aesthetic as well as the functional sense.
Now, researchers in Spain and at MIT have managed to image light itself. Which means that we can see light in motion. No, not the movement of other things in light. But the process of light moving.
For example, we can watch a video of a mirror forming a reflection. That's exactly what this video shows. Science-fiction has once again caught up with the world we live in. This is more than a bit mind boggling, so I hope to explain.
All you have to do to start an argument is to bring up the topic of "traditional" Irish stew. Everyone will think they have the correct version, usually based on what their mother cooked. But of course there is no permanent tradition. A stew is any combination of meat and vegetables cooked in liquid over time, and even in Ireland there are many variations. Some are served with a broth, others are thick. Some made with lamb, others beef.
What follows will be my own version, which is hearty and delicious, the perfect autumnal food. (Even for those, such as I, who would eat red meat rarely.) Before getting on to the recipe I will write a bit about the history of this dish in Ireland.
Explore my many activities using the main menu above and search form below. Subscribe in each category to get new articles automatically. Visit my master page for even more. Email "robin [at] robinparmar [dot] com".
recent posts: all
Please contribute what you can to fund my research and artistic activities. Every little bit is appreciated. Thanks!