Hi all,
I decided it would be best to break the discussion regarding this tool
into a separate thread. For the discussion that led to the development
of this tool, see the "A Rant From Mr. Grumpy on ZF2" thread.
Per the earlier discussion, I have put this project up on GitHub:
https://github.com/EvanDotPro/zf-statusI have a live copy up at:
http://zf2.evan.pro/There are currently a few issues I'm aware of:
- Branches are mapped 1:1 to components. I built this tool very
quickly without much thought, not knowing how useful the finished
thing would be. Now that it's beginning to show some real value, I
plan to refactor it to more accurately map branches and commits to the
appropriate ZF2 components as m:m.
- The GitHub API restricts requests to 60 per second. I'm using
Zend_Cache to address this; but currently it performs a bit over 60
requests to generate the page. If you're trying the current code out,
and you run into that issue, simply refresh after a minute, and it
will continue building the cache where it left off. Here are my
thoughts:
- Unfortunately, loading per-component data on-demand via ajax
won't help much. Due to the way it's aggregating the data from many
forks and branches, and how the GitHub API works, it's not much less
expensive gathering the data for a single component than it is
gathering the data for all of them, so we may as well just load it all
up front.
- Certain requests such as those for user data could be cached for
much longer periods of time.
- I'm going to make a simple CLI switch for rebuilding the cache,
which will throttle the requests to GitHub as to not hit the 60
req/min limit. It will then be trivial to cron it to update at any
interval desired.
Per Nick Belhomme's suggestion (Re: "Status page created"), I am
contemplating the idea of parsing the mailing list for component
names, and having it organize the relevant threads under each
component. I think this would be a simple, yet incredibly useful for
helping developers who don't stay completely up to date with the
mailing lists be able to follow discussions on a per-component basis
with much less effort. While it's true that modern e-mail/webmail
clients (not to mention Nabble) have extensive search capabilities, I
think doing this sort of basic filtering and providing it up front on
a page that developers are likely to stumble across could go a long
way towards helping diminish the "closed door" feeling people have
been expressing. I realize everyone may not agree on the usefulness,
but I think it's safe to say it definitely wouldn't hurt.
Finally, I've resisted the urge to hook this into any sort of database
backend (MySQL, MongoDB, etc) for the sake of not over-engineering a
simple tool. However, having a relational database of users, commits,
branches, components, and their respective relationships would really
open up some awesome possibilities. I'm not saying it's a good idea
and I really think doing something like that would snowball this
small, simple project into something much larger and more complicated
than it needs to be. I'll just say that I'm at least modestly open to
the concept should a cool enough idea come up to warrant the
complexity.
So anyway, enjoy, feel free to fork it and play around; or just give
your thoughts or ideas here and I'll do my best to implement them as
time permits. I'll try to stay on top of all pull requests, etc.
Hopefully the community finds this little tool useful in following the
progress of ZF2!
--
Evan Coury
--
List:
[hidden email]
Info:
http://framework.zend.com/archivesUnsubscribe:
[hidden email]
Locked
