The CFP is a Call for Papers application for Conferences.
The application allows a speaker to register with Github/Google+ or LinkedIn, then post one or more proposals for a Conference.
A program committee can then vote, ask questions to speaker and finally, build an Agenda for a conference. The CFP offers also a REST API with the list of selected talks, speakers and the schedules.
In 2015, the Devoxx France's CFP received 681 proposals for 220 slots. The 16 members of the technical committee for Devoxx FR did more than 6700 reviews in 2 months.
Original author: Nicolas Martignole @nmartignole
- Gabriel Kastenbaum @lambdadevfr
- Jean Helou @jeanhelou
- Frédéric Camblor @fcamblor
- Nicolas de Loof @ndeloof
- Mani Sarkar theNeomatrix369
The CFP application is licensed under the MIT License. See License.txt or http://opensource.org/licenses/MIT
Copyright (c) 2013 Association du Paris Java User Group & Nicolas Martignole.
The CFP was originally created in 2013 for the Devoxx France 2014 edition. Devoxx France is one of the biggest conference for Developers in France with 2500 attendees in 2015. The conference had top sponsors like Google, Oracle, IBM and Microsoft. The conference is organized by Nicolas Martignole, Antonio Goncalvès and Zouheir Cadi.
The CFP is implemented with Scala and Play Framework v2.2.3. Redis 2.8 is used for persistence. Elastic Search is integrated as a search engine and to calculate stats with Facets.
- Devoxx France
- Devoxx Belgium
- Devoxx Poland
- Devoxx UK
- Devoxx Morocco
- Web2Day Tech2Day
- BDX.IO
- Scala.IO
- Breizh Camp
- Droid Con
Send a message to (@nmartignole)[http://www.twitter.com/nmartignole) if you plan to use the CFP.
- Install Play 2.2.3 (not the latest version with activator)
- Install Redis 2.8.21 (or better, but NOT Redis 3.x), do not use "brew install redis" on Mac, as it would install 2.6, an older version of Redis
- Read Redis documentation and learn Redis with http://try.redis.io
- Read also the self-document redis.conf https://raw.githubusercontent.com/antirez/redis/2.8/redis.conf
Optional but recommended for better user experience:
- Install ElasticSearch (1.2.0 or better) This version uses Facets.
- Create Github App and configure OAuth. See the Github site
- Create an application using your Google account. Configure a URL for development, such as http://localhost:9000/ and prod URL as http://cfp.devoxx.fr/
- Create a LinkedIn App and configure OAuth
- a Mailjet account for SMTP sending transactional emails
- Rename the run.sh.sample file to run.sh
- Generate a string for the security of the application application.secret = "a_unique_secret_long_enough"
- As the application uses play.api.libs.Crypto#encryptAES, this secret MUST be at least 16 chars long.
- Configure the SMTP server using the parameters Mailjet OR use the smtp.mock mode in DEV
- Configure the Github part
- Set the Google party for authentication OAuth2.0
- Configure also LinkedIn
- configure the Redis server. Make sure to set a very long password for your Redis server
- configure the address of a server ElasticSearch
First things first, you need to set-up your own conference. To do so, Frederic Camblor implemented a generic class that contains most (but not all) importants details. Check ConferenceDescriptor.scala. This file defines the configuration of your own conference. The Schedule/Slots is not mandatory when you start to configure your application. However if you plan to use the REST API then you should also configure this part. Check for the TODO's in the file.
You can then also translate and check messages/messages.fr from the conf file
To create an admin:
- Start the CFP with a local Redis server
- Create a new User (http://localhost:9000/home) with the Registration system
- If you configured smtp.mock="yes" in application.conf, check the console. You should see the "please validate your email" message
- Loads and validate your user
- Once authenticated, retrieve your UUID from the "Edit my Profile" page (/cfp/profile)
- Load the bootstrap URL http://localhost:9000/admin/bootstrapAdminUser?uuid=[your_uuid]. Please note that if there is already an admin, this won't work.
You can also add an existing user to the Admin group directly from Redis console :
The main development branch is dev. It' an out-of-the-box ready to use conference. This is also where I try to collect all features from all contributors.
I created a branch dev-france for current development regarding Devoxx France. I did the same for BE. I work with one feature per branch, then do local merge.
When you want to update your local branch (for instance, dev-poland) you should :
- do a checkout of dev
- do a git pull --rebase on dev
- switch to dev-poland
- do a git pull --rebase from dev to dev-poland so that you keep your local updates
Use WGET and download all pages from your Publisher controller. This will save speakers, talks, schedule, etc.
wget --no-clobber --convert-links -r -p -E -e robots=off http://localhost:9000/2014
Downloading redis...tag.gz from http://download.redis.io/releases/redis-2.8.21.tar.gz
The CFP has been tested with Redis from version 2.8.4 to 2.8.19. Always check that your version is up-to-date in term of security here. I plan to upgrade and to check that the CFP code is OK with Redis 3.x before Devoxx France 2016.
Unpack the archive
$ make
$ make install
Create a custom redis configuration file. Be sure to set a very strong password. Redis is written in C and is mono-core. On my super Intel i7 it runs on one Core. Thus it's ok to have multiple Redis on differents ports.
How to run the redis server with custom config file ?
$ redis-server [xxx.conf-file]
Note: ensure all paths in the .conf file exists otherwise, use touch to create those files / paths
How to run the redis client ?
Once the redis-server is up and running, do the following:
$ redis-cli -p 6366
Some commands to remember:
> INFO
> DBSIZE
> SYNC - helps sync remote server with local server (cluster)
> MONITOR
> SMEMBERS Webuser:admin
> SADD Webuser:admin [sha1]
Once running on a local empty Redis, you will want to have a local user with admin privileges in the application.
-
Create a user and activate it
-
Play log will give you the activation link if running on smtp.mock=”yes”
-
Connect to the Redis instance
-
Find the UUID of the user you want to be admin
-
The command keys Webuser:UUID* will list all known user UUIDs
-
Find which one is your soon to be admin by running get Webuser:UUID: and the output gives you the email.
-
Add the UUID to admin and cfp groups using redis-cli (the redis CLI).
SADD Webuser:admin SADD Webuser:cfp
If you want to promote an existing user to admin on your PROD server, you can also use redis-cli to connect to the remote server Let's say you want to add John with ID=UUID_123456 to the remote PROD redis-prod.mydomain.com that is running on port 6393. The Master password on this remote server is "my_super_password_for_prod".
nicolas@macbook :~/Dev/DevoxxFR/2014/RedisBackup> redis-cli -h redis-prod.mydomain.com -p 6393
redis-prod.mydomain.com:6393> info
NOAUTH Authentication required.
redis-prod.mydomain.com:6393> AUTH my_super_password_for_prod
OK
redis-prod.mydomain.com:6393> SADD Webuser:admin UUID_123456
redis-prod.mydomain.com:6393> SADD Webuser:cfp UUID_123456
...
- Restart the application to clear its caches (or use /admin/clearCaches if you are already an admin and connected)
First, read the Redis documentation. I use AOF and BGSAVE on my production servers. I also use Linux Dropbox client so that I can save some dump automatically. I have also configured my personal computer to be a slave of all my Redis servers. This is very practical, you get a live copy of Redis on your laptop.
See redis-sample-dev.conf and redis-sample-prod.conf for 2 valid configuration files for Redis.
Just to give you an idea and some stats for our Devoxx France 2015 Redis database :
- Number of Speakers : 946
- Number of Proposals : 681
- Number of Reviews : 6704
- Redis DB Size : 8388
- DUMP file size : 65M
- AOF file size : 73M
- Number of lines in the AOF file : 2,344,818
- Memory used by Redis : 142 Mo
The Devoxx France CFP is hosted on Clever-Cloud. Clever Cloud is a Platform as a Service. Git push and voilà, your code is deployed. Redis and ElasticSearch are on a dedicated server.
I recommend Play 2.2.6. I have a strong experience with Play since 2011 and Play 1.x. I did more than 20 presentations of Play! Framework since 2010.
I plan to evaluate the need to migrate to Play Framework 2.4. But I'm not a super-fan with this version and with what the core developers decided to do since early 2015.
Pull requests are welcome but be aware that the CFP is really focus on Devoxx conferences.
The following is a list of absolute requirements for PRs (not following them would result in immediate rejection):
- You MUST use space for indentation instead of tabs
- The coding style MUST be followed exactly (default IDEA IntelliJ 14 settings)
- Each commit MUST be a single change (e.g. adding a function or fixing a bug, but not both at once)
- Each commit MAY respect the Commit log convention (see below)
- The pull request MUST contain as few commits as needed
- The pull request MUST NOT contain fixup or revert commits (flatten them beforehand using GitUp!)
- The pull request MUST be rebased on latest
dev
when sent
We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history.
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is mandatory and the scope of the header is optional.
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
If the commit reverts a previous commit, it should begin with revert:
, followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>.
, where the hash is the SHA of the commit being reverted.
Must be one of the following:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
The scope could be anything specifying place of the commit change, usually related to a Play Controller. For example admin
,
api
, publisher
, etc.
The subject contains succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize first letter
- no dot (.) at the end
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.
Breaking Changes should start with the word BREAKING CHANGE:
with a space or two newlines. The rest of the commit message is then used for this.
A detailed explanation can be found in the AngularJS Git commit documentation.
Merci
Nicolas Martignole