Development features wishlist

Out of date:

This page's accuracy may be compromised due to out-of-date information. Please help improve the page by updating it. There may be additional information on the talk page.

Note:

This page is from 2013, so somebody should check if the list still contains useful points. If not, it should either be updated or deleted. We also have another list on Current and future development (which I partly updated); maybe they could be merged into one list. --waithamai talk 06:38, 17 August 2017 (UTC)

Below is a curated feature wishlist of things the core team would love to have some help with for the Diaspora project.

If you choose one these features, a core team member will help you get your pull request merged. It is a fast-track way to get involved with the Diaspora* codebase.

Community developers are more than welcome to dive in and work on these at any time, please contact the mailing list about any of the items listed below that you’d like to help with. Also, don’t be afraid to join in and help out other developers with existing projects

“In Development” items will be linked with a thread to Google groups, so as to encourage collaboration and avoid duplicating effort.

1) Refactor AppConfig and EnviromentConfiguration (in progress)

AppConfig is the current class that handles loading Diaspora’s settings from application.yml. It has grown into a bit of beast, worrying about bootstate, data munging, and a few related helpers. The time to clean it up is now! We should move all logic out of AppConfig, and let it just be a SettingsLogic class. Then, we should access everything via EnvironmentConfiguration, delegating applicable keys and to AppConfig.

2) Help make things easier for other developers

Many projects have a script which makes it trivial to get a development environment running. It would be awesome to have a script that bootstrapped the minimum environment needed to run the entire test suite. That way, it would be easy for new developers to clone the repo, run the script, and run the tests, all in one swoop. As a start, which should make this process seamless for the following three environments (then we can work on something more general: 1) Mac OS X; 2) Ubuntu development; 3) Virtual Box Setup (we can host the final box).

3) Refactor Cucumber features

See these? Now see how much worse this is? A lot of our cukes are messy, it would be great if someone with a great sense of code clarity were to refactor some of the features. If you want to go the extra mile, work with Dennis and identify tests that would be better in Jasmine, or unit tests to shave some time off the suite as well.

4) Refactor controllers

There are a bunch of things a seasoned Rails dev would want to do here. Utilize more rescue_froms to reduce branching, breaking really big actions into objects that are delegated to, to just improving and backfilling tests. This is not the most glamorous of things on this list, but it would be much appreciated.

5) Improve admin interface

We already have rails admin running. It might still need some configuration tweaking. We could make a couple of static pages, and move some of our custom functionality to the rails_admin side of things. Other ideas are basic webfingering other pod dev tools, showing the list of connected pods, and adding links to things like resque status etc etc.

6) Pod customization (in progress)

We’re discussing how to turn some variables into strings to make pod customization easier for podmins without needing to fork from the main codebase. It’s a great starting point for figuring out how further to customize a pod.

7) Save image dimensions with every image file

Need to upgrade Carrier-Wave, and include a hack in the Carrier-Wave wiki.

8) Fix delayed image processing BS

Related to number 7. Ask Max for more info.

9) Welcome email

After a user has signed up, email them with helpful information.

10) Clean out images folder (in progress)

There’s a lot of unused images in there that we don’t need, so it kind of makes for a waste of space.

11) Carrier-Wave improvements

Make Carrier-Wave upload to a /tmp directory for tests, and clean up when done.

12) Improve mobile site (DONE)

Currently, our mobile site is relatively simplistic, and could use some tweaking to be made more accessible. A discussion needs to happen to figure out what new features would be desirable.

13) Add tests to this pull request

This was contributed to us by a user. It’s a relatively simple fix, but the contributor was unable to write tests for it. Let’s help this person out and make sure that we can get it merged in!

14) Document the code.

Please document the existing code and also consider documenting your code as much as you can when you send us a pull request. It helps others who fork the repository to understand and work on it.

New things to be worked on

Things needed to be fixed at hand. Started from a conversation between @raven24 and @maxwell

Evil query …. use the scope_operators from Makrio (btw. the amount of inline code comments is probably not TOO DAMN HIGH# enough - I think we really want to get the wisdom inside/next to the source, rdoc for (most of) the code might be helpful for new devs…) get some SQL wisdom in there.

→ so, maybe a walk-through of the evil query parts might help (soon-ish)

Batch stuff using find_each more -> possibly together with Resque/Sidekiq switch - receive loop - sending loop.

Federation and stuff make receive be runnable again and again encapsulate into objects and separate into layers (throw a HTTP request at the “federation layer” and out comes normalized XML/JSON - or the other way around) notifications…. de-fuckify them - don’t try to use more magic than we actually can handle. better more verbose code than a mess that causes problems - completely decouple them from federation state. move federation to json? Maybe start over? general theme of trying to think of discrete phases? - decouple database layout from the protocol messages structure object serialization. - be liberal in making multiple ruby classes - serialize to an in-memory presenter, which dumps to an ORM object - allow db state to reach across in memory objects

1. receive message
2. validate envelope, parse json, put in queue => return actual response …

Background processing Resque => Sidekiq advantage: threads instead of processes, less memory more fun potential job for junior devs, API looks similar.

Rails upgrade - gems - security! [[Category:Github transfer done