Reactive programming with Python RxPya project by SShyukriev I'm planning to get basics of Reactive Programming and especially the documentation in ReactiveX and try some examples from RxPy |
Make "salt-toaster" available to be used outside SUSEa project by PSuarezHernandez The |
Integrate Bard with MusicBrainz and implement a proper web interfacea project by alarrosa My music manager, Bard, was improved in the last hackweek with a very simple React-based web interface but I didn't like the result at all (basically, after learning React I noticed I didn't like it and all the dependencies and the complexity it added) so since then, I've reimplemented the web interface using just jQuery. Also, in the last months I've added musicbrainz data structures to the database (which was also ported to use Postgresql) to prepare bard to use MusicBrainz's data. I also stopped using other python libraries to read audio files and use the ffmpeg libraries directly instead with a c++ wrapper implemented inside Bard which is much much faster. |
Port Salt virt modules to idema project by cbosdonnat Salt is moving towards a plugable architecture using POP and Idem. This project is about experimenting with those new concepts by applying them to a real life case: the virt execution and state modules. |
reading a book: <<How Google Tests Software>>a project by llzhao Project Description |
Improve mtk scripts and improve on python skillsa project by bfilho |
The Missing Middle: Add an intermediate brightness setting for auxiliary LEDs in Andúril 2a project by gkenion |
Build and validate a scale-out Samba/CTDB cluster atop CephFSan invention by dmdiss Samba and CTDB rely heavily on POSIX fcntl locks for data and meta-data integrity. This functionality was recently fixed in CephFS, opening up the possibility to use CephFS as an underlying filesystem for a scale-out Samba/CTDB cluster. |
All documentation as program codean invention by jsmeix I like to try out if it is possible to write a program that does not have any kind of the traditionally separated documentation (like external files that contain the documentation texts or comments in the program code). Instead all documentation must be implemented as code at the same place where the matching functiomnality is implemented (i.e. each function implements also its documentation). In the end the user should get only the executable that he can run to let it do the intended functionality and also to provide any kind of documentation. What I do not want is a dumb '--help' option that lets the program spit out its built-in documentation. What I would like to have is that the user can run the executable in some kind of self-inspecting way. I mean: While it does the intended functionality, it can also provide documentation so that the user can explore the program while running it. In the end the user experience should be more like a text adventure ;-) |
Check p2v tool (guestfs)a project by aginies Test the latest release of guesfs tools, and chech new p2v. Package it for openSUSE |