YJL

tl;dr http://pipes.yahoo.com/pipeslivibetter/newrubygems

I have been monitoring Python Packages for quite some time, few days ago, I wanted to expand to the gems on RubyGems.org. Sadly, it doesnt even have any feeds for newly created packages.

The best option for me is to utilize the /api/v1/activity/latest of the Activity APIwhich has XML, JSON, and YAML formatswith the help from Yahoo! Pipes:

$ curl 'https://rubygems.org/api/v1/activity/latest.json'

You can grab the feed at http://pipes.yahoo.com/pipeslivibetter/newrubygems.

Thhttps://bitbucket.org/grandpas/e.bashe source looks like:

It only took me 10 minutes or less to figure out how to make such conversion. This was my first time to use Yahoo! Pipes to convert a JSON to an RSS feed.

Although it works well and is very simple, this isnt my ideal solution. I actually asked someone who knows about Ruby to add feed support and timestamp to RubyGems.orgs source code. Thats not going to happen by the person I asked, so if you know about Ruby and you have time, please think about adding such feed to it.

I am thinking to create a couple of issues, but not really sure if I should do that since I dont think I can even call myself a Ruby user.

Before that, well, this feed would do just fine.

The PyPI newest packages feed contains 40 entries, thats 40 new packages. As of writing, it spans back about 21 hours, 3 of 40 are those A simple printer of nested lists spams, for those I had even filed an issue to PyPI issue tracker, I was told:

Richard Jones: I regularly clean out these modules. Just try to ignore them.

As you can guess, I am really sick of those. Everyday, at least three are spams if not less. Wasting time to go through that feed, 7.5% of spam rate, thats not an insignificant number by any means. I just could not believe that I had waited for three months to do something.

So, here it is a cleaner feed¹ with the help of Yahoo! Pipes, once again:

You can see two filters, first one is for the spams, seconds are for other legit packages that I am not interested in. Off-topic: the quality of packages are usually low, some are not even ready, links send you to 404. I really dont know why those people bother wasting others time and theirs.

This action was actually prompted by someone who was asking about my Ultimate YJL feed, reminded me of the usefulness of Yahoo! Pipes, should have thought about using Yahoo! Pipes, this pipe only took me about 10 minutes to lay down after 3 months of wasting time on skipping through.

Only 26 packages got through, 14 are removed. 14 actions less to take every day. 14 keypress might not sound a lot but multiply by 365, its 5,110 presses a year. And if you are a mouse clicker, you are wasting even more.

What, mileage? Its a mouse not a flight!

---

[1]	http://pipes.yahoo.com/pipeslivibetter/pypipackagesfiltered is gone with Yahoo! Pipes.

DoBy looks very interesting, basically, it will raise exception when the current time has passed the specified time, for example:

>>> from doby import TODO
>>> from datetime import datetime, timedelta
>>> delta = timedelta(seconds=1)
>>> now = datetime.now()
>>> TODO('I need to come back to this', now + 60 * delta)
>>> TODO('I need to come back to this', now - delta)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "doby/__init__.py", line 38, in TODO
    DoBy(note, doby)
  File "doby/__init__.py", line 28, in __init__
    raise self
doby.DoBy: TODO: I need to come back to this
>>> TODO('I need to come back to this', now)
Traceback (most recent call last):
    ...
doby.DoBy: TODO: I need to come back to this
>>> TODO('I need to come back to this', '17-05-2013')
Traceback (most recent call last):
    ...
doby.DoBy: TODO: I need to come back to this

Interesting as I said, but it might not be reliable due to the nature of the code. Think about coverage.py, got what I am thinking about it? The raised exception might come too late or never come.

Still, this is a unique conception to implement a notifiable TODO.

DoBy is written by Adam Drakeford under the MIT License, currently version 1.0.2 (2014-05-17), for both Python 2 and 3.

I saw this python-progressbar package when I updated my system, its part of Gentoo Portage tree. When I saw it in the output report of eix-diff, I thought: Really? a library for progress bar and it is included in Portage tree, really?

I checked out its examples and ran it, then I knew why it is a library and its in the tree. Thats a lot of awesome examples and many of the progressive styles which I have never seen before. So I made a video with an additional example ^_^:

REE is something I created last September and never really made useful out of it, well, since it wasnt supposed to be. It was made only for fun. But when I saw the animated bouncing progressbar, I knew thats where REE can chime in.

I probably wont create an issue for the modification for this REE example, because REEally?

After I made a script for visualization of Portage Tree as wheel, small modifications now enabled it showing you the tree as the tree.

The following image is all packages in the tree:



And installed packages on my system:



Both images are re-sized to 1024x269. You can view the Bash script.

(Also posted to Gentoo forum)


Seeing a visualized dependency graph of a package should be always interesting. I read a post on Arch Linux Forums, which generates very beautiful images of your Arch Linux. I was thinking to add a support for Gentoo, but after reading the code, I decided to write my own completely.

Actually, I only did a half of work. My code doesn't not render the image but using Graphviz to the job. It requires packages gentoolkit and graphviz. There are few usage examples written at top of the script.

Here are two quick examples: First one is the Dependency of portage


Second one is big, whole world highlighting python.

You can read the code and download it.

The result should be reflecting installed packages and used USE flags on packages at the time of installing. I didn't take a look at the results very deep, so I am not sure if they are 100% correct since I don't know if I interpreted the data from gentoolkit correctly or not.

I think it's fun to see the visualized dependency data. The code needs Graphviz to render the image, and I think I didn't configure it well. So if you generate whole world, the result is hard to read.

Hope you would like it and give me some feedback.