Ricerous, A Community Project About Ricing

This thread is to keep track of a project.

Introduction:

We've tried to pull out many community projects in the past and they all failed
to fulfill their purpose. Recently, on irc, some of us were discussing this
matter and tried to give new ideas for a solid project. The main concern was
that to regroup the community we needed a project that everyone could
contribute, had knowledge about, and liked. The word "ricing" came to our mind
and we started brainstorming what projects we could all work on, that would
touch this subject, that would help other people, and that would, in a sense,
regroup the community.

The Idea

A kind of portable wiki diary program about ricing. It regroups altogether what
can be riced with useful information and link about it. It also let the user
notes/comments in each sections to keep track of what has been done. The notes
can then be exported/imported in multiple formats.

Goal

• [X] Make it easy to redo another person's setup.
  [X] Remove the mystification around the word "ricing".
  [X] Easily share one's setup on forums/boards.
  

User Base

Beginner ricers that don't know where to start.
Advanced users that get lost when they want to share info about their setup.

Scratch pad

etherpad
The information

Requirements

• [X] Easily browsable definition/links/info of things by sections
  [X] Easy way to recognize what has been selected and re-browse through it
  
• Links should be visible
  [X] Save config/setup of the program
  [X] Editable output format (to stdout)
  [X] Editable places (comments) to keep track of custom actions
  [X] Pluggable/easy to add new things (programming side)
  [X] Local / Portable
  

Use Cases

• Open the Program Presented with the last section visited
  
• Search for a keyword (only if the interface is bad)
  [X] Go into a specific section and check the info/links/description
  [X] Tick a box as it being in the current install
  [X] Add comments to section that can be exported/imported
  [X] Load / Save configs/setup/comments(of the program) in a sharable manner
  
• add a new section/edit --> send it online for approval ~~most tricky one
  

Mainly 2 cases:
[X] "I don't know what I'm doing what's that thing called a shell... oh that's it, let's see what I can do and add it in the comments" or
[X] "I wanna keep track of what I did config in my shell, ah yeah I forgot to add my aliases"

Mock-ups & User Interface Designs

In the same order as in the scratch pad, meaning in the same order that they
have been done. You can follow up the conversation about them on the pad to
argue about them.

• (z3bra)
  
• (venam)
  
• z3bra2 (z3bra)
  
• (venam)
  
• (dotdev)
  
• (jolia)
  

Class Diagrams

Same thing as with the UI, to get more info read the pad.

• (venam)
  
• (kirby)
  

Implementation
Here is the community repo: https://github.com/nixers-projects/ricerous

[/list]
List Of Riceable Things And Info
Please refer to this pad.

What Needs To Be Done

• Test/Debug the Program (Doesn't need programming knowledge)
  

What Has Been Done
[X] Means that it has been fulfilled in the above requirements and expectations.
Here are some screenshots of the program:





How To Test
Install kivy.
Continue on with the tutorial & sharing thread http://nixers.net/showthread.php?tid=1579

Contributors

• Z3bra
  
• Dami
  
• Foggalong
  
• pizzaroll1 (kaashif-hymabaccus)
  
• Jolia
  
• Kirby
  
• DotDev
  
• Dcli
  
• Venam
  
• Vompatti
  
• Earsplit
  

The rest of the community for giving ideas, opinions, and helping choose a name.

I like the idea, in general. Not overly worried about ricing my desktop, so my interest in contributing is low.

That said, I've often thought that the Linux world would contribute from a single "main-line" distro with different package management systems and packages for the variable bits and pieces, including themes and the like. Likewise, if making packages weren't such an epic pain in the ass (for things like what I'm about to suggest) more people could create a package for their setup. E.g. the theme, wm config files, all the other stuff you mention above. I know the FHS aims to achieve this to some extent, but SuSE is still a pack of retards, and there are others that don't always play nice either.

(19-07-2014, 11:44 AM)sodaphish Wrote: That said, I've often thought that the Linux world would contribute from a single "main-line" distro with different package management systems and packages for the variable bits and pieces, including themes and the like. Likewise, if making packages weren't such an epic pain in the ass (for things like what I'm about to suggest) more people could create a package for their setup. E.g. the theme, wm config files, all the other stuff you mention above. I know the FHS aims to achieve this to some extent, but SuSE is still a pack of retards, and there are others that don't always play nice either.

I have not a single clue what you are talking about.

(19-07-2014, 11:44 AM)sodaphish Wrote: That said, I've often thought that the Linux world would contribute from a single "main-line" distro with different package management systems and packages for the variable bits and pieces, including themes and the like. Likewise, if making packages weren't such an epic pain in the ass (for things like what I'm about to suggest) more people could create a package for their setup. E.g. the theme, wm config files, all the other stuff you mention above. I know the FHS aims to achieve this to some extent, but SuSE is still a pack of retards, and there are others that don't always play nice either.

A lot of systems have packages that look very easy to make. Go ask z3bra about crux, that doesn't look too difficult, and yrmt has written an entire blog post on pkgsrc. I also think baking the configs into the packages is counter-intuitive myself, as it's harder to take apart a package, edit, and repackage every time than just having the package provide a binary and a config file.

As far as contributions go, there's a lot to add to the designs and the like without having to write any actual code. As I don't know python myself, I'll probably end up sticking towards this side more. I'll also be happy to actually do the writing about the things that can be riced as well.

(19-07-2014, 03:49 PM)kirby Wrote: As far as contributions go, there's a lot to add to the designs and the like without having to write any actual code. As I don't know python myself, I'll probably end up sticking towards this side more. I'll also be happy to actually do the writing about the things that can be riced as well.

We chose Python, for the moment, because it seems like the easiest language to use to implement what we want. However, there are still rooms to argue about that.

Thanks a lot for helping out.

Can't this just be some sort of frontend for making and distributing Ansible playbooks or some other configuration management thing. It's a lot easier to make it cross-platform, too, because there are loads of pre-made modules for dealing with package managers and OS-specific quirks. Like openbsd_pkg, apt, yum, pkgng and other modules (for Ansible, I don't really have much experience with Puppet, Chef or others) that let you ensure packages are installed before installing configs or whatever.

Ansible is also written in Python and has a very easy to use and useful API.

It could be overkill, though, the same things could conceivably be done with a shell script running uname and a massive "case $(uname) in OpenBSD) .... Debian) .... FreeBSD) ...." with a list of all of the operating systems.

(20-07-2014, 08:47 AM)pizzaroll1 Wrote: Can't this just be some sort of frontend for making and distributing Ansible playbooks or some other configuration management thing. It's a lot easier to make it cross-platform, too, because there are loads of pre-made modules for dealing with package managers and OS-specific quirks. Like openbsd_pkg, apt, yum, pkgng and other modules (for Ansible, I don't really have much experience with Puppet, Chef or others) that let you ensure packages are installed before installing configs or whatever.

Ansible is also written in Python and has a very easy to use and useful API.

It could be overkill, though, the same things could conceivably be done with a shell script running uname and a massive "case $(uname) in OpenBSD) .... Debian) .... FreeBSD) ...." with a list of all of the operating systems.

I don't understand why you are all talking about package management. The program won't install anything. Maybe it's not well explained. I'll re-read what I wrote thoroughly.

Am I mistaken in thinking that "Make it easy to redo another person's setup." means you tell the ricing helper something then it installs all the configs and programs and makes your setup exactly like theirs? Or do you only mean give info about someone else's configs?

(20-07-2014, 09:48 AM)pizzaroll1 Wrote: Am I mistaken in thinking that "Make it easy to redo another person's setup." means you tell the ricing helper something then it installs all the configs and programs and makes your setup exactly like theirs? Or do you only mean give info about someone else's configs?

It doesn't necessarily mean tracking configuration files and copying them into someone else's computer. Reproducing someone else's setup is usually a more complex task and it doesn't have to be related to any configs. Also, what about the case where a user only wants to reproduce a part of another setup. Moreover, simply installing a bunch of stuffs doesn't teach you anything while reading the way it was done in a comment or note will.

There are already ton of tools to track files but do they really teach people how to reproduce a setup? In most of the cases it's a no and in the cases where it works there are too many architecture/hierarchy differences between the distros/OSs that it mostly fails.

Remember the main user base for this program is the "beginner ricer".
I am not saying that tracking configuration files is a bad thing but does it fulfil our needs?

Never mind then, I had the wrong idea about what you intended for this program.

Maybe this would help. It's the output from what venam already wrote. It's not working yet, but it provides the expected output (or at least, an overview of what it aims to do)

Here's my UI prototype

It's just something I've mocked up in Python/Kivy, but if people are interested in seeing this in action I can start to add functionality as in venam's script.

I would be really interested in helping out with this project in anyway possible. I had the same(ish) idea a couple of weeks ago but I never thought I could get any sort of traction or the desire to start the project.

I don't have a problem with people forking and experimenting, what I've done so far uses purely Python, Kivy and it's dependencies, whatever they may be for the particular system.

I have a publicly available repo on Github so feel free to fork and have play with it, even give me pull requests if you think you have something worth sharing.

On that topic, I was thinking of forking something and starting on the actual writing component, if people are ok with this? Or would it be better to go somewhere else?

kirby: If you want to you can start working on implementing the code (you can check what I have written on github for inspiration) or help filling up the information. Dami0 is on a good track about the UI.

I'm planning to spend a lot of time this weekend fetching information for the program and trying things out. Anyone, feel free to join me on the pad.

Hopefully I'll have some time tomorrow and I'll be relaxed enough to pump away into the night coding like a mad man. If anyone wants to try a group coding session, reach me on IRC or this thread.

I know nothing about Python but I'd be down, I could discuss and help through ideas around and stuff.

For those who want to help, I updated the TODO list.
I'll re-post it here.

What Needs To Be Done

• Review the list of riceable things. (Doesn't need programming knowledge)
  
• Start to fill up the information about every sections and titles. (Doesn't need programming knowledge)
  
• Help building up templates for outputers like html,markdown,bbcode,etc.. (Doesn't need programming knowledge)
  
• Help Dami with the frontend (Kivy). You can help him with the placement of the widgets if you have no programming knowledge.
  
• Help Venam with the backend (the class diagram that I posted above has been implemented)
  
• Maintain the pad/brainstorms/thread.(Doesn't need programming knowledge)
  

If you feel like you want to do one of the above join the pad.
https://titanpad.com/gtvzILOtdT

do you Invision this to be online, or local? if local, why not just create a git repo with a simple markdown parser in an HTML file and a load all the content from the md files? 'ricers' will just need to clone the repo and open it in their web browser of choice. i could whip that up in a few minutes. then it's just a matter of focusing on writing content. we could add a scraper in the js to compare the local git commit hash to the remote one and prompt users when there's an update. just thinking aloud...

I don't want to use JavaScript since we're already working with Venam on a Python/Kivy (GUI maker) version that is already sort of usable. So far we are planning to use .json files on a Git repo to make it easy to port your configs to different machines and different people. We are handling Git externally so far, as far as I know so if you want to help with that, we'd be grateful.

Here's my repo and here's Venam's. I'm doing the GUI and he's working on the backend (mostly) for reading in the .json files which makes me a happy hippo.

If you were wondering what Kivy is.

I'd like to help too. I know python and some C, but I prefer none programming related tasks (for now) don't really have the energy for any more projects at the moment.

That is great. We need someone to fill out the info on titanpad or work on the info.json file to fill out categories and information on them. Talk to venam on IRC about this.

I updated the TODO list.
Here it is:

• Review the information on the pad http://titanpad.com/ricing. (Doesn't need programming knowledge)
  
• Get more ideas for outputers templates other than html,markdown, and bbcode. (Doesn't need programming knowledge)
  
• Help Dami with the frontend (Kivy). You can help him with the placement of the widget if you have no programming knowledge.
  
• Maintain the pads/brainstorms/thread.(Doesn't need programming knowledge)
  

I've updated the TODO list and the first post.

Here's the TODO list, for the rest recheck the first post.

• Review the information on the pad http://titanpad.com/ricing. (Doesn't need programming knowledge)
  
• Get more ideas for outputers templates other than html,markdown, and bbcode. (Doesn't need programming knowledge)
  
• Help cleaning the frontend code (Kivy)
  
• Choose a name for the program (Doesn't need programming knowledge)
  
• Test/Debug the Program (Doesn't need programming knowledge)
  

I added a poll for the program name.

I would humbly submit "rice cooker". I mean it's perfect. Right?

I updated the TODO list, refer to the first post for more information:

What Needs To Be Done

• Choose a name for the program (vote)
  
• Review the information on the pad http://titanpad.com/ricing. (Doesn't need programming knowledge)
  
• Write a script to easily convert the info on the pad to JSON readable by the program
  
• Help cleaning the frontend code (Kivy)
  
• Add comments to the code
  
• Test/Debug the Program (Doesn't need programming knowledge)
  
• Package the program
  
• Choose a license
  
• Get more ideas for outputers templates other than html,markdown, and bbcode. (Doesn't need programming knowledge)