Had similar struggles as well. Then after few experiments with plain paper (tried A4, B6, A5 - all landscape), I switched to Midori Paper Pad, carrying it in a leather pouch. Using A5 on the go and A4 on my desk. All in landscape orientation, like slides. My output is mostly diagrams/schemas and tables, very little prose.
Advantages so far: high quality per that works with fountain pen. No fear of ruining whole notebook with an ugly note or a drawing. I can carry only sheets that are relevant to the problem I am solving right now. I can lay out the sheets in front of me to get a bigger picture. I can throw away the bad ones. It is easier to scan (using iPhone scan to PDF function).
Can confirm, MUJI notebooks are of a decent quality and they can handle fountain pens as well.
In addition to that, I gradually switched to their 0.38 pens of different colors. With fountain pen it was more stylish but impractical for multiple semantic(*) colours. With cheap, light, yet nice quality pens of different colours I can not only carry multiple ones, but have the same set at multiple places.
(Dark blue is body text/drawing, light blue is comment/secondary annotation, orange is action/process/message passing, green is data/metadata flow, …)
In Czechia and Slovakia we have mapy.cz which gives you more detailed map for walking/hiking, including contour lines. See [^1] for example.
The coloured trails you can see at more detailed zoom levels, are part of the hiking trail system. The outdoor signage even has a national technical norm [^2] (in Slovak, but has some terminology translated int to English and German).
Author here. I admit, it has been more than a year since I made a significant contribution. It kind of correlates with change of my job – since I started to work with my current employer I didn't have almost any time to work on neither of Data Brewery projects directly. All I have is full notebook of new ideas and mailbox of unanswered feature requests and bug reports. It makes me sad, but honestly I don't know how to proceed.
I really enjoyed working on Data Brewery and I eventually will resume my work as there is a lot to do. It is just put aside on the back burner. In the meantime I might only hope that someone would volunteer to at least handle bug fixes. I'm open to grant access to the repositories.
Any suggestion how to prevent open-source project from dying is welcome.
Author here. They are very independent. In short: Cubes is OLAP framework for abstracting aggregate queries on top of a datastore, mostly through SQL. You define a so called multi-dimensional model – how the analysts see the world, and cubes knows how to project it to underlying data structures, preferably star or snowflake table schemas.
Bubbles was meant to be data integration library (also known as ETL) – get data from multiple sources, transform them and produce tables that are more suitable for further analysis or reporting.
I don't think we can equate complexity of a tropical thunderstorm to the complexity as described in the article. The discussed complexity arises from local connections (be it persistent bonds or repeated interactions) between entities. While interactions in the thunderstorm might seem "complex" to our mind, they are not "complex" from the point of view of "complex systems", they are rather "complicated".
Moreover thunderstorm network (if we consider the interactions of particles in the thunderstorm) is very transient. No feedback loops emerge in the system (to my understanding of thunderstorm). Also the system does not adapt to the surrounding environment through it's reconfiguration of internal connections. Thunderstorm lacks many properties of the complex systems discussed in the article.
There is one advantage in people mispronouncing your name though. In my experience, people within a group tend to converge towards one pronunciation or variation of your name. On a random encounter in public or out-of-the group environment, if someone is addressing you, you know which group he/she is from, based on the pronunciation he/she used.
I think that if people were more familiar with Smalltalk, the Objective-C would not get that bad rating. I find the Smalltalk message passing syntax is way more readable than more common function(args) syntax. ObjC is nothing more than a plain C with message passing in square brackets.
What might make it less attractive is the verbosity of Cocoa (formerly known as OpenStep), too many class name prefixes, missing native literal objects and use of pointers. This is problem of the framework, not the language itself though.
That reminds me SOAR[1] (from 1984): Smalltalk on a RISC
Smalltalk on a RISC (SOAR) is a simple, Von Neumann computer that is designed to execute the Smalltalk-80 system much faster than existing VLSI microcomputers. The Smalltalk-80 system is a highly productive programming environment but poses tough challenges for implementors: dynamic data typing, a high level instruction set, frequent and expensive procedure calls, and object-oriented storage management. SOAR compiles programs to a low level, efficient instruction set. Parallel tag checks permit high performance for the simple common cases and cause traps to software routines for the complex cases. Parallel register initialization and multiple on-chip register windows speed procedure calls. Sophisticated software techniques relieve the hardware of the burden of managing objects. We have initial evaluations of the effectiveness of the SOAR architecture by compiling and simulating benchmarks, and will prove SOAR's feasibility by fabricating a 35,000-transistor SOAR chip. These early results suggest that a Reduced Instruction Set Computer can provide high performance in an exploratory programming environment.
It's about the principle. I'm not saying that the problem has no solution, I can convert the files using someone else's computer as you are saying. Why should I get a USB CD drive that I will use only to convert documents that I expect to be readable anyways? Why should I spend time looking for someone with iWork'09 installation and use their time to convert my documents? It is just unacceptable from a company that is proud for user experience of its products. I should be able to do that from my chair, legally, with a download of a conversion tool or with an upload to a conversion service from Apple, not a third-party.
I would not mind buying a floppy drive and all necessary adapters, install Atari ST emulator and write Kamenicky encoding converter in Python to convert 1st World Plus documents from '89 if I had to convert documents of my parents. I would not be complaining about obsolescence of the format at all.
My problem is not technical, it is about user experience and productivity.
FFS, this is "HackerNews"... write a bash script to do it for you.
I have written quite a few bash scripts, python scripts and long ago ruby and smalltalk scripts to do things for me, that bothered me. My point is, this is a software I am paying for (and I've already mentioned that 2008 should not be considered as old) and I would rather spend my time writing the "super 1337 h4x0r" bash and python scripts for something that I can't do otherwise.
You are right, I can get all the necessary hardware for that. That is not a problem, problem is that I can't have that when I need it. Imagine you go to a meetup and would like to show some older presentations and you are not aware of the issue. Well, bad luck - nothing to show, no quick fix by downloading a conversion tool or older version of the software.
I'm not saying that it is permanent problem, there is solution for it for sure. It is just unnecessarily cumbersome and mostly unexpected: I can imagine dropping support for files from 1995 not for files from 2008.
You are right, it is not true of all proprietary software. There is no problem with software upgrades, not even with frequent software upgrades. Problem is when the software requires regular document upgrades. This requirement can not be met in real life, if you produce few documents a month.
Etoile is great project with many interesting concepts. I always wished that Apple would somehow get inspired by the LanguageKit. I guess that AppleScript was good enough...
Thanks Marcel. Nice work with Objective Smalltalk too.
Irony is that at that time the Smalltalk people didn't see the advantages of frameworks like StepTalk. I got a few "Why don't you just use Smalltalk?" questions on ESUG conference in 2003 – on one hand they were not happy that Smalltalk use was a bit declining (or at least not thriving, compared to other languages/environments), but didn't wanted to see a compromise solution. Only the pure Smalltalk way was the proper way.
> Maybe it's an idea whose time has finally come :-)
... where web == one large distributed Smalltalk image? I'm all for that! ;-)
StepTalk is another Smalltalk-ObjectiveC legacy framework, originally meant for Smalltalk-like scripting of ObjectiveC apps/tools. It was built for GNUstep but worked on early versions of Cocoa as well: https://github.com/stiivi/StepTalk. It is no longer maintained, therefore it might need a little bit of refreshment.
Advantages so far: high quality per that works with fountain pen. No fear of ruining whole notebook with an ugly note or a drawing. I can carry only sheets that are relevant to the problem I am solving right now. I can lay out the sheets in front of me to get a bigger picture. I can throw away the bad ones. It is easier to scan (using iPhone scan to PDF function).
https://md.midori-japan.co.jp/en/products/mdpaper-pad/