sorted by: recent | see :
popular
Content Tagged pimki
Pimki 1.8.200
Important note: this release is still based on the Pimki 1.x branch. Snapshots from previous versions of Pimki and Instiki up to 0.9.2 should work fine.
Work on Pimki2 is back into full swing - watch this space!
Go to http://pimki.rubyforge.org for the full scoop. If you're running gems just run 'gem install Pimki' and it will be installed/upgraded for you. Otherwise just download, unzip and run!
== About
Pimki is a PIM (Personal Information Manager) loosely based on a Wiki technology inspired by Instiki. This is the place to dump your brain, organise your thoughts and Get Things Done. The ease of use and immediacy of a wiki combined with extended view to slice and dice the data give you a unique power to store, manage and retrieve all loose bit of information in your life.
There are a lot of features added over a regular wiki, features that only make sense when you view it as a personal application and not so much as a group oriented application.
== Extra Features
=== Mind Map: a graph of wiki connections (made with GraphViz). All graphs can be laid-out with the 4 GraphViz engines. There are several options for what pages to include in the map. Graph contents can be arranged as:
* Page → linked pages
* Authors → pages
* Categories → pages
=== Bliki: a blog integrated with the wiki. Blog entries are simply wiki-pages in a special space, organised in reverse-chronological order.
=== Todo Items & List:
* ‘todo:’ items are highlighted on each page.
* Pull all todo's into a main list, to better prioritise your work
=== Added left-side customisable wiki menu
=== Expanded and Advanced search
=== A Glossary page, collecting all acronyms from your web
Pimki update
So here's an update: After the user survey (yeah yeah I still haven't published the results), I come across the following conclusions:
- Instiki is dead. It's unfortunate but it's a fact of life that its maintainers do not bother to respond to emails.
- My users are techie, and are more concerned about the backend integrity than how to install it.
Despite the second point above, I think KirbyBase is better for Pimki. Even though it's not integrated into Rails, than say SQLite, it is still something I can better control and support. The ability to have a "just works" application is priceless. The couple of months of setback in dev time for Pimki have given me a much better understanding of ActiveRecord, and better options for my users. Pimki is now developed with both KirbyBase and SQLite is mind and is tested on both - You will have the simple life of plain text storage, or you can install and run it on any Rails' supported DB backend.
So for the last couple on months I have been working on Ackbar - An ActiveRecord KirbyBase Adapter. I have release the first experimental version last week, and am now giving it a good bashing. A few other people have expressed interest, including Jamey Cribbs the creator of KirbyBase. We have identified a few minor issues already, but overall it works pretty well.
So now I am back at full time Pimki. Since Instiki was actually holding up Pimki development, I am doing a full reimplementation. I will borrow code and inspiration from it, but will no longer be dependent / impacted by changes. I am now designing the data model that will best serve Pimki. It already includes a few enhancements I was planning on for some time.
The data model relationships are mostly done, and I now move to the actual model logic. This is probably the trickiest bit: decomposing a text section into data objects and components. It's very nice to have a section of prose with an embedded TODO item, but it's something else to process it flawlessly. The approach I am taking now is of decompose-on-save, i.e. the page will be processed as much as possible on creation / update and then saved/cahced as parts. The page will be reconstructed on display, and the cached bits may be used directly (static content like acronyms) or expanded (dynamic contents like page links to newly created pages or todo items which have been updated).
It looks like Pimki2 will center around stability and GTD features. I have a few more ideas up my sleeves around those areas, and already a growing list of ideas and requests for javascript based goodies which will be in Pimki 3.0.
So there you have it. I am back at full time (full hobby time that is :) on Pimki and I have absolute TONS of ideas on where to take this forward!
Ackbar hotflash
Go check it out, but let me just comment that I'm fixing the issues he find in CVS as fast as I can, and there will be a new Ackbar release when he's done :-). I have also started work again on Pimki, concentrating on the data model. That will no doubt have impact on Ackbar. More updates soon, but for now go read his blog!
Announcing Ackbar
About Ackbar
Ackbar is an adapter for ActiveRecord (the Rails ORM layer) to the KirbyBase pure-ruby plain-text DBMS. Because KirbyBase does not support SQL, joins or transactions, this is not a 100% fit. There are some changes to the ActiveRecord interface (see below), but it may still be useful in some cases.
URIs
Ackbar: ackbar.rubyforge.org
KirbyBase: www.netpromi.com/kirbybase_ruby.html
Rails: www.rubyonrails.com
Pimki: pimki.rubyforge.org
Goals
Ackbar’s project goals, in order of importance, are:
- Support Pimki with a pure-ruby, cross-platform hassle-less install DBMS
- An exercise for me to learn ActiveRecord inside out
- Support other "shrink-wrapped" Rails projects with similar needs
As can be seen, the main reason I need Ackbar is so I distribute Pimki across multiple platforms without requiring non-Ruby 3rd party libraries. KirbyBase will work wherever Ruby works, and so will Pimki. That alleviates the need to repackage other bits, end users will not have to install extra software, I have full control on the storage, the storage is in plain text. Just what I need to "shrink wrap" a Rails project for end-user distribution.
What’s Covered
Ackbar currently passes through a small bootstrap test suite, and through about 80% of the ActiveRecord test suite. I will never pass 100% of the tests because KirbyBase does not support all required functionality.
Ackbar includes a SQL fragment translator, so that simple cross-database code should be maintainable. For example the following will work as expected,
Book.find :all, :conditions => "name = 'Pickaxe'"
Book.find :all, :conditions => ["name = ?", 'Pickaxe']
Additionally, you can also provide blocks:
Book.find :all, :conditions => lambda{|rec| rec.name == 'Pickaxe'}
or even:
Book.find(:all) {|rec| rec.name == 'Pickaxe'}
Most of these changes are around the find method, bit some apply to update and associations. Basic SQL translation should work the same, but you can always provide custom code to be used. See the CHANGELOG and the tests for examples.
What’s Not Covered
- Transactions
- Joins, and therefore Eager Associations
- Mixins
- Other plugins
On the todo list is support for mixins. It might even be possible to rig something to simulate joins and eager associations, but that is for a later stage. Transactions will obviously only be supported once they are supported by KirbyBase.
Additionally, there are numerous little changes to the standard behaviour. See the CHANGELOG and the tests for more details. These may cause little heart attacks if you expect a standard SQL database.
It is also worth noting that other plugins that write SQL will not work. You will need to get a copy of them to your /vendors dir and modify the relevant parts.
Installation
Simply:
gem install ackbar
or download the zip file from rubyforge.org/projects/ackbar and just stick kirbybase_adapter.rb in the Rails lib dir.
You will then need to add
require 'kirbybase_adapter'
in the config/environment.rb file of your project.
If you plan on multi-database development / deployment, you must require the adapter only if necessary:
require 'kirbybase_adapter' if ActiveRecord::Base.configurations[RAILS_ENV]['adapter'] == 'kirbybase'
This is because Ackbar overrides certain methods in ActiveRecord::Base and others. These methods translate the standard SQL generation to method calls on KirbyBase, and obviously should not be overridden for regular DBs.
Now we go back to our regular scheduled programming, consisting of mostly silence as I actually code more than I write about it. More updates *soon* :-)
Goodness, I need a vacation. Or a beer. Definitely a beer
So. I have a new job which I enjoy tremendously but it keeps me busy during daylight. I come home to spend a bit of time with my family, till later at night. Then, if I can manage it, I get do a bit of Ruby.
Not a lot mind you, but it's fun.
What's currently on my ruby red plate:I've mostly decided on the direction Pimki is going in (I know, I know I promised to publish the survey results ages ago; I'm getting to it, honest!). In order to have the best solution for Pimki, I am writing a Rails ActiveRecord adapter for KirbyBase - the pure-ruby, plain-text DBMS. This has been taking most of my OSS time of late. Would have taken more but for the most excellent support from Jamey Cribbs, KirbyBase's developer.
Instiki is currently in weird zombie state. I think Alexey is in a similar state, and has very little time to update it. When I'm more or less done with Ackbar (i.e. it does what I need it to to support Pimki), I will take the then most current working version of Instiki and build Pimki2 on it + KirbyBase. This will probably be the last time I will do that. If there is any future work on Instiki - new features, bug fixes etc - I will evaluate them one by one and port them to Pimki only as I see fit. The current pace of Instiki development (looong periods of inactivity followed by MASSIVE, half done changes.... with minimal version increases), is just not something I can deal with.
So we get to the 1158th project listed on Rubyforge: Ackbar. What this means for Pimki users (myself included) is
- A pure-ruby database: no madeleine crap, no external dependencies, no cross platform issues. This is where SQLite fails. By the nature of Pimki it has to Just Work. Mucking about with repackaging SQLite is an unnecessary complication both for me and for my users. (Not that I don't thing my users could handle a simple DLL, but if there are any problems - I can't do anything about them).
- Plain text: In a pinch, it's really easy to get at your information. Again, no madeleine binary formats that cause me headaches between versions. The DB schema can be managed easily with AR migrations.
So far I have the basic schema operations working, and most of the CRUDs (delete still won't, but I'll spank it into submission). I am currently fleshing out the tests to make sure that further development is stable and that features already implemented do cover all aspects. After that it's foraying into the AR associations (all the nice has_xxx methods). At this stage I don't think I'll use the built in Link_many and Lookup functionality of KB. I'll let AR handle that as a regular relational database.
The other downside is that there are minor API changes from "vanilla" ActiveRecord. After all, some of the SQL features just don't make sense, while a more rubyish interface is a natural extension. So while you may not be able to just drop it in place of another database in an existing Rails app, it won't be a lot of work to convert.
That's it for now. I hope I get time update this blog (and - god forbid - read other blogs) in the coming months. Even if I don't please be assured that I'm hard at work on Ruby. I have never been happier since giving up commercial programming, so that when I DO get to program, it's done the way I like it. I just hope the future quality of my projects will show this.
Pimki2 - The Zombie Release
As for the true blue Pimki2 (hey look, I can rhyme! badly!) - it's coming. I'm investigating writing an ActiveRecord adapter for KirbyBase myself (mostly myself - I plan to... er.. borrow much from Logan Capaldo's KirbyRecord). So I could both use ActiveRecord and the DB of my choice.
The results of the recent Pimki users survey (published as soon as I get off my arse and collate them) stress simplicity, one-click-install over everything else. As a developer, I prefer using AR as it is integrated more tightly with the rest of Rails. But of course I want the best of both worlds with the benefits of KB (pure-ruby, plain-text).
So I'm attempting to write this myself.
Just don't hold your breath.
This also give me a something better to do than just wait for Instiki to complete it's transition. This fork will apparently be the last time Instiki core can be integrated as-is into Pimki. I plan to introduce many code and schema changes, addition and tweaks that it will no longer be possible to simply reuse Instiki (partly because Pimki needs a simple database, and the current options do not support AR:Migration). I will support importing Instiki webs into Pimki, but not through the backend. I will continue borrow features from Instiki, but the process will be more of a reimplementation with hints from Instiki.
Back to the backend, if I fail to make KB and AR play nice (KB is not a relational DBMS - it doesn't support SQL, which AR kinda assumes all databases do), I'll reconsider my options. Instiki will come bundled with SQLite, but even Alexy recommends MySQL "for any serious scenario". User data is always a serious scenario to me. Plus, I introduce way too much schema changes between revisions myself, but SQLite does not support AR:Migrations. So I might bite the bullet and write my own migrations for every release, or I might use KB without AR.
Only time will tell, but feel free to make side comment in the mean time.
Features done in meetings
I don't know about the vaunted 10x productivity of Rails, but that's only because I haven't done much web-work otherwise. All I can tell you is that for Pimki I added two new features (and a bug fix)... while I was sitting in a meeting and came across the need for them!
Embedded GraphViz graphs
As I was taking notes in a lecture (using Pimki on a brand shiny new laptop), I needed to copy a diagram from the whiteboard. Laptop are not notoriously easy in that aspect, but the diagram was simple enough and I know that dot language reasonably well. So as the meeting went I just typed the graph into a page. During a short break I added a new chunk that looked for such embedded graphs, runs GraphViz and replaced the text with the image result. (Well, the short break wasn't quite enough and I did spend that evening fixing this, but the point, man, the point!).
So if you're using Pimki2 and update to the latest CVS snapshot (be warned - still alpha), you can embed a GraphViz diagram in a page with the help of <graph></graph> tags. Just read the help section.
Google Searches
In
another meeting, I wanted to take a note to search google on something.
What better way that to extend the existing external links with a
Google search? Just embed a [g[query string]] in the page and you're laughing.
Of course, just adding more such links is not the full solution I'm after. But until I get a chance to do the full macros, it'll do quite nicely.
Not bad for a couple of meetings in which I also managed to learn a few things :-)
As for the bug-fix, in the upgrade to Pimki2 I managed to miss the ToDo text expansion - the rendering of the text after the todo as part of the page itself. That is not fixed and links to pages, glossary items and the like are displayed correctly.
The next major item on the list is still the backend format. This is also the major holdback in development - almost everything is dependent on how the information is stored. (So if you use Pimki, please fill the user survey at: http://rubyforge.org/survey/survey.php?group_id=447&survey_id=25!)
Currently there are two contenders: SQLite and KirbyBase.
SQLite comes with Instiki-AR, but I think KB may have other advantages
that merit consideration: Import from Instiki can still be acheived
through export/import (and that may be the case anyway with
Instiki-AR); It is a pure-ruby solution, so nothing extra to install;
It uses plain-text to store the data; I like the ruby-blocks format of
querying data. The major disadvantages is of ActiveRecord: KirbeyBase
is not an SQL format and there is no AR adapter for it. This means I
can't learn-by-example from Instiki and that I miss out on all the
existing goodness like the #acts_as_taggble mixin. I will
also lose on changes from Instiki, but since I'm not sure about how
continued integration will work (expect for export/import) anyway, and
that may turn out well in that it will force me to better review each
change in Instiki and get a better understanding of what goes in where.
What I need is mainly time to play with both options. Not a thing I have in bounds, so I'm asking questions on ruby-talk and here. If you have any experience with these issues, please feel free to contact me directly or on the pimki-users mailing list.
The joy of doing everything again. Again.
With the release on Instiki-AR, I am now faced with a difficult problem: should Pimki remain with madeleine or switch to SQLite?
(Bottom line: I need to know my users better, so if you use Pimki please please please fill this survey!).
Background
When DHH first implemented/released Instiki, it was based around his ideas for how Rails will turn out to be. At the time I was both learning Ruby and looking at ways to better organise myself. So I started hacking Instiki to add navigation, personal productivity and other features. David was not interested in integrating them back into Instiki main, as they reduced the "no step three" installation (the GraphViz dependency) and simplicity on Instiki. I continued to work on it in the dark for awhile, but at the insistence of Gavin Sinclair, I release it publicly on RubyForge (an inssistence I now repay back regarding Gavin's patented CrapCollctor ;).
Going public has really pushed me forward: adding more productivity features at users request, getting exposed to GTD, learning more about proper development and testing practices, better Ruby and Rails knowledge and other goodies. So a big Thank You for all the users who responded over the years! (It also meant continually merging and upgrading with the Instiki source code mainline never knowing the release schedule and contents and the effort required for each upgrade but I'm not complaining I'm just sitting alone in the dark developing this for your eternal gratification and productivity)
Then around Instiki version 0.9.1, DHH was too busy to keep maintainint it and the task was givem to Alexey Verkhovsky. Alexey has release 0.9.2 as a patch release and went to on migrate Instiki to the modern rails. So between the minor release of 0.9.2 and 0.10 Instiki had gone an astounding transformation under the covers, from being based on a precursor of Rails to Rails 0.11! (<rant>When will people realise that 1.0 is not a shameful / all is perfect release, and that major changed to the API should be noted with major version number changes?!?!?</rant>)
I tried for a while to integrate Instiki 0.10 into Pimki, but gave up on this as too problem prone. There was no way I could do it and remain sane. So instead I declared Pimki2 - the new generation of Pimki. (See? major changes => major version and I haven't been smitten with lightning yet). What I did was take a fresh copy of the new Instiki and re-implement all the features. Besides the underlying changes, there is also a big philosophical move: Pimki 1.x was a hack to make it work; Pimki2 is a Get It Right phase, where I try to build it better in a sustainable way. This means better tests (TDD), cleaner code, new fetaures with a more critical view of the feature set etc. The upside is a better piece of software, the downside is that the released version (Pimki 1.8 currently) is still in the old code base.
Current State
So we get to the now and point of this post. When I finally had most of the features back to the state they were before, plus a few enhancements and the skeleton of what I want to achieve for a Pimki 2.0 release at an alpha stage...
Alexey goes and releases Instiki-AR - Instiki with an SQL backend...
And then announces that he really doesn't have a lot of time keep maintaining Instiki...And that there's this newfangled I2 thingy anyway - a rewrite of the major features of Instiki in Rails to make a proper Rails-based wiki.
Going forward
So here are my options, on which I'd really appreciate your feedback (and if you can't be bothered to take the survey, you can always email the pimki-users mailing list or just me):
Continue with madeleine
Pros:
- Simplest thing to do (nothing)
- Everything required is still pure-Ruby, so easiest to install and minimise cross-platform issues
Cons:
- Madeleine is problematic. Upgrading and debugging can be a pain. It also very rarely (but it happens) generates corrupt snapshot when using the zlib compression.
- Harder to continue importing stuff from Instiki
Use SQLite
Pros:
- Much more stable backend
- Can take advantage of Active Record
- Technical users can change the DB easily to run on whatever they wish
Cons:
- Yet again I'll have to rewrite everything (but hopefully less so in the future)
- This is not absolutely necessary. Madeleine can be nasty, but it's functional. This extra work means less work on the PIM features, which are much more important to me (and I guess my users).
- No longer simple install in most cases. Gem install means having to install SQLite on your own. Zip install means I can include the DLL on windows (and possibly Mac), but Linux users will still have to get it themselves (easy on debian/ubunto, harder on others). And considering I don't have a Mac handy (yet), MacOSX support will be very limited.
At this stage I'm leaning towards using SQLite. Here are my reasons:
- This will solve my need for a stable system.
- At this point, Pimki2 requires you anyway to export previous contents and import them back in. This situation is likely to stay, and will be the only to import Instiki webs anyway.
- I expect most of Pimki's users to be technical enough to handle the simple SQLite install, or be on Windows where it will be less of a problem. And considering you need to install GraphViz or the Mind Maps anyway, another simple external dependency is not a killer.
- Downplaying (but not abandoning) the gems install means that I have better control over the version of Rails and other libraries included. I expect gems users to be techie enough to handle the missing requirements.
My course of action will be to study the Instiki-AR schemas, play around with them, enhance as necessary and then re-implement the 2.0 features. Timewise, it'll be awhile (patches and help are always welcome :) before Pimki2 will be back to alpha. Once there, I hope the new features will be a lot easier to implement and maintain.
Thanks for reading down to the bottom. Any response, comment or insight on this problem will be much appreciated.
Life round-up
From Bruce Tate and Joel's Forums come a couple of light reading pieces about the state of affairs in the Java world. Not much to add, except that this is why I've made the decision that if I don't get to code Ruby, I'd rather not code (professionally :) at all.
And before anyone points out the diminishing costs of starting-up, I have given this some thoughts. In a time where I was looking to leave my current employer (aka the tar pits of oblivion), this was very appealing. But life has other notions, and I do have some obligations. So I am changing places (next week - woohoo!) to a new employer with a much more supportive environment but minimal coding, and I'll get my fix coding open-source.
On the one hand, it's much less coding than I'd like but on the other hand I get to work on things I have passion for, and at least enjoy the environment during daylight. So expect a continued stream of innovations in Pimki... but at very fluid deadlines :-) I currently have many more ideas than time and I really enjoy this project, so Pimki will remain alive and kicking albeit in slow-motion.
And maybe one day, when life is lessing pressing, I'd get off my butt and start working on that nifty idea...
Rails - Faster than a speeding bullet
As Instiki/Pimki are getting an SQLite backend (as opposed to the current object prevalence layer Madeleine), I will need to manage the growing difference between the two.
And, because I've been asked about it already, because the schemas are platform agnostic it will also allow users to use a different database backend. All the well-known one-click goodness for simple usage (download and run, sqlite binary included), plus the power users' option to tweak the storage (want a different database due to religious reasons? no worries! just run rake migrate).
Moving house
Sorry, just had to let it out of my system :-)
My life this past week looked like a cubist painting, all in boxes. I've been wading in packaging materials trying to find my life and there has been little time for the bare necessities (like email).
On the plus side, the Pimki 1.8 release seems to have gone without a hitch. Even though I hit the send button for the release only moments before having packed the computer. I fully expected to see a mailbox full of angry users and bugs, but everything went really smooth. I must be getting better at this :-)
Download numbers are rapidly approaching 4400, but I'd like to issue a formal statement that Pimki has no connection with alien abductions. We have not taken you aboard our alien spacecraft to alter your mind for extra productivity, nor are we experimenting with symbiotic intelligence enhancers. We are just good this way :->
On the Pimki2 front (obviously quite this past week), I am waiting for Instiki's SQLite backend. It seems like Alexey is developing it for the next Instiki release, as Madeleine (which handles object perssistance) is just a shade too wonky. In the meanwhile I'm polishing other aspects of Pimki, and hope to get a chance to contribute a little to Instiki and help as much as I can.
Todos in Pimki
While I'm waiting for the dust on Instiki's SQLite back-end to settle, I've been doing some front end work for Pimki. First order of the day: better todo display (the other major todo upgrade - making them checkable - depends too much on the storage mechanism).
The most visible change is that the combined Todo view now comes in two flavours: plain list and quadrant view. There is a full documentation in the help section, BTW.
The Enhancements
You can now set a few properties on the todo items, besides context. The full syntax is:
todo@context{importance: high, due_date: Dec 23}: buy chrissy prezziesThis
allows you to break your tasks into both urgency (when) and importance
levels. Other properties will be ignored for the moment. One property
that I'll add soon is status, for marking the items as complete. Still need some thoughts about how this should be handled (re display, archiving, etc).
An
additional enhancement is that todo items now automatically pick up the
enclosing page categories as their context. So if you have a todo@home on page with category:garage listed, the context for that todo is both home and garage.
The List View
The list view is basically the same as before, tweaked for better display. You can sort the display by name, dates or importance. You can limit the list of displayed items by context. Each item will link back to the page/entry it is set on.
The Quadrant View
This is inspired by The 7 Habits of Highly Effective People. The idea behind it is that we tend to do important and urgent things first, then move to urgent but not important tasks. Instead, more time should be given to important but less urgent tasks (read this for a bit discussion). This view will collect all the todo items and display them in a table for easy reference on what should be done next.
Currently, the urgency horizon is set at 1 week: if it's due before then it's urgent, otherwise it's not.
Under the Hood
Under the hood I've split the Bliki and the Task Tracker into their own controllers. As a testament to the 10x hype with rails this exercise took about 10 minutes per controller, and I ended up with more tests. What I did was use script/generate to create the new controller, then copy over the relevant methods and tests from the Wiki controller to the new one. I added the necessary routes entries, changed a bit of the action names and run the tests. It didn't take long to make everything in the tests pass. I then grep the code to find all the things I haven't changed, added tests (that failed) and fixed the code. So overall the result is better (I hope :).
As I edit the templates and controllers, I also try to modernise the code. Taking advantage of all the built-in Rails functionality makes Pimki less of hack and a lot easier to manage in the long run.
Next steps
The next things on the list are to streamline the Bliki interface and complete the (AJAX heavy) Task-Tracker front end.
If you are interested in checking Pimki2 while under development, read my last post on how to. Short version: export existing, download, unzip, stop old, start new, import, play. Just don't use it for mission critical data yet :-)
Pimki2 - Ready for alpha testing
Here's what to do, for those interested brave souls:
1. Get a tarball of the latest source.
2. Unzip somewhere
3. Export a previous Pimki in markup format and save the zip file. (It's also recommended to get a snapshot of the latest Pimki 1.x - the 1.8 maintenance release will be built soon).
4. Run as usual, but it's probably better to use a different port number than Pimki.
5. Create a new system and a new web.
6. Go to 'Web Setup', then 'Import zip' near the bottom.
7. Import the previously saved zip.
Here's what's new and working (and what's new and not :-)
- If you import from Pimki (rather than Instiki), all the original page authors and creating times are preserved. Only the latest revisions are exported/imported, though, to preserve space.
- There's a new help system for all the features, so don't panic.
- Task Tracker is halfway there, but wobbly.
- The Snippets and Macros aren't implemented yet.
- Hyperbolic Mind Maps are there - a per-page map of inbound and outbout links.
- Content templates are there (for new pages only at the moment). You'll first need to go through the Web Setup page to add a few templates.
- Two new stylesheet are available, for the not-easily-visually-offended (I'm an engineer - design help is VERY welcome :-).
- Glossary items are (should be :) highlighted on usage (ie. define an acronym on one page, het the tool tip everywhere else).
- Bliki, ToDo items, Mind Map and advanced search are all there and
working at the same level as Pimki 1. Enhancements are soon to follow.
This release is mainly for testing. If you do come across an issue, just email me. I am very open to patches, especially in the design front :-)
Instiki is now getting an SQLite backend, so I hope to pick that up as soon as it's ready. That one reason why I hold of on backend intensive changes to Pimki (the other reason is my copious spare time).
What else is coming? ToDo items will have an associated due-date and importance, and a table view to make sure you do the important bits, not just the urgent ones; Bliki interface will be streamlined. Snippets and macros will be implemented; The look and feel will be polished.
I'd love to hear feedback, but be gentle - this is an alpha release.
blech
misc
This looks madly cool: MoochiKit
- A lightwight javascript library (moto: MochiKit makes JavaScript suck
less). A highly documented and well tested suite of JavaScript
libraries that will help you get shit done, fast.
I wonder long till it's integrated with Rails? :-)
(from lesscode.org)
If you've got time, go read We are the web
by Kevin Kelly. Fills you with a kind of buzzing energy that makes you excited about the future. (from too-biased).
Backstroke of the West. No comment
(from Bill de hÓra).
Computer update: making progress on installing everything, then
going to customise the beejezus out of it (again) so I have the colors
and keyboard shortcuts and software preferences juuuust right to go
back to development. At least I've got email back.