Blog‎ > ‎

Open Data, Message Queues, Python Web Frameworks, GIS

posted Apr 20, 2014, 9:48 AM by Sami Lehtinen   [ updated Apr 20, 2014, 9:50 AM ]
  • Checked out the Open Personal Data project MyData project. Also watched their YouTube videos and visions. I did notice that there's no plan for generic receipt standard. Here's also a forum discussing about Finnish Open Data standards (Fin: AvoinData) and requirements.
  • I also got information that NRF has an e-receipt standard, but it seems to be a secret standard. I sent them an email asking for the documentation and specifications. What's the use of secret standard? I already complained that Finvoice is complex standard, but secret standard is much worse than complex standard. It's almost as good as no standard at all.
  • Played with Tesseract-OCR engine, unfortunately the source image quality wasn't good enough for the purpose I tried it for. It basically requires high quality scans and images captured with mobile phone camera just won't work with it. Well, maybe I'll try it again later, or try some other library which could be better doing OCR with lower quality images. It's also worth of noting that mobile phone cameras are developing fast. I'm not sure if image pre-processing would have improved the situation. I don't wonder poor results, sometimes mobile phone snaps glare or are blurred so badly that those are annoying, slow or even hard for even humans to read. If it would have worked well, I have had an idea for a new website service concept, that doesn't currently exist at all.
  • Server hosting is getting cheaper and cheaper, usually cost of servers is nearly to nothing, compared to the cost of work. I guess this is bad for optimization and low level stuff. Here's new all SSD hosting plans by Linode.
  • Checked out PASM - Pyston World's first X86-64 Assembler working in the web browser. That's bit too low level geekery for me.
  • Studied CloudFlare web-sockets & SSL support. It seems that there's no web-sockets support.
  • Spent a few hours playing with snakeMQ and Redis, both worked nicely between four virtual Ubuntu Servers in VirtualBox containers. These solutions allow much higher performance, than the traditional it work's but isn't pretty thing, which is using SQL tables as queues.
    Often the reason for using SQL tables as queues, is that it keeps the system stack simpler. Often for small projects, I really prefer keeping number of different technologies being used to minimum. It makes life for everyone easier. I kind of got assaulted in one group because I talked about SQLite3, they told that there are other professional database solutions out there. Yes, but if I just want to run simple script on random low end system. I don't want to install any massive enterprise database for that. Because installing and configuring the database, is 100x the job that the project needs to setup completely when using SQLite3. And what if someone wants to run the project on Raspberry Pi, it should also work without any problems, from 16G SD card, including operating system in that space. Another example is the next row.
  • Studied Digital Ocean comparison of Python based web applications. It's of course possible to setup Nginx and uWSGI, but because uWSGI already includes perfectly capable web-server, why to install Nginx and complicate setup as long as it's not required. I also liked these posts, Python Cloud Web-Applications and How To Structure Large Flask Applications. It seems to me that the Flask is pretty hot framework right now.
  • Added separate projects page. Future will tell if it will be maintained. I personally prefer simple and easy to maintain solutions. Having same stuff in different places and cross-linked can be hard to maintain.
  • Started to study Android own URI schemes and Android intent including data android:scheme and action android:name inside native intent-filter.
  • Checked out JulkICT, Finnish Open Data project.
  • Studied basics and concepts of currently available Location Based Services (LBS) in Finland and Europe. It's clear that LBS data will be widely used, but many of the older web businesses doesn't seem to have picked it up.
  • Studied Geographic Informatino Systems (GIS), PostGIS and spatial databases and required indexes.