Can the backend send all timestamps in milliseconds instead of seconds? The tool we use for parsing json in android does not support seconds (and switching is not an option), so otherwise we would need to manually updating the fields.
The same goes for frontend, if they ever forget to multiply by 1000 the dates will break.

Alright @armada-ths/system-developers, I thought this would be good to bring up before tomorrow's meetup. Full disclaimer: I'm pro open source. I've tried not to be too biased though :)

To be clear we're talking about open sourcing the code, not the data.

Pros

• It's a nice way to compensate us for our work. We're not getting paid but open sourcing the code at least gives us public attribution for the work we do, which is a nice incentive.
• We should be building awesome stuff and open sourcing the repo lets us show off our awesomeness to the rest of the world (potential employers etc.). This is similar to the previous point but it's worth making explicit: This is probably one of the few "real" projects some people will work on during their time at KTH and being able to show off their code to future employers is a big deal.
• It's good karma; since we use a lot of open source it's nice to at least give others the chance to benefit from what we do.
• It forces professionalism, or at least encourages it. People are less likely to write commit messages á la F$CK YOU DJANGO!!1! if their work can be publicly attributed to them. Unless you're Linus.
• It's a good recruitment tool for future years. If we're awesome and can show people that we're awesome, they'll want to be like us. Right?
• Free access to Github integrations like Travis or Codeship. The actual cost may or may not be an issue (money stuff isn't really our problem), but it's no fun waiting for @mictab to email back and forth to haggle the price. Everything is just easier if we open source the code.

Cons

• There could be severe business implications. The career fairs at all the universities in Sweden are an extremely competitive business and having great IT gives Armada a significant advantage. Open sourcing the repo could potentially help the other fairs.
• If we aren't awesome it will show. People have bad days and it might be uncomfortable to share them with the rest of the world.
• There are security concerns. We can't have deploy keys in the repo, for example, and having the code publicly accessible increases the risk of people finding exploits.
• There are confidentiality concerns. We can't just dump last year's data in the repo to use as test data, for example.
• Server secrets might need to be re-generated. It's possible that they've been in the repo at some point and could be found in the history.

Edit:

• React with 👍 if you think we should open source the repo
• React with 👎 if you think we shouldn't open source the repo
• React with 🎉 if you don't have a strong opinion either way

And also assign new roles with the same permissions for a new year.

Doesn't look good as it is for the moment.

Craft an automatic setup script, perhaps a bash script, to automatically set up a server, this will also give a good overview of which commands to run if you want to manually setup a server. Use the dev database by default, but ask if they would want to use a different file.

Someone who has never worked in our system should be able to get a server setup in less than five minutes following basic instructions in the readme.

What branching model are we using here? From what I can see there's master and recruitment branches and a bunch of other branches that haven't been updated in a while. I don't want to step on anyone's toes by basing off of master :(

This is kind of related to #3 and #8, I'll update the README with the answer :) 👍

The readme is outdated, running a local server is much easier now, and the documentation should reflect that.
Also, mention common errors on dev/prod, such as "Bad gateway", e.g service is not running (run uwsgi ais_uwsgi.ini to fix), or migration errors (Can often be fixed with python manage.py migrate --fake)

Mention how to update servers (apt upgate/upgrade and running the contents of "pip_upgade.txt" under scripts.

We should add some kind of monitoring and error tracking to AIS. I don't have any experience with good monitoring services so if anyone do please comment. 😄 I can do some research but any help is appreciated.

This is probably not prioritised but I just wanted to get it out there.

As @walaro said in #25, it's probably a good idea to regenerate the server secrets before open sourcing the repo in case they're present in a rogue commit somewhere. Someone that actually has access to the production server (I don't 😢) will have to do this. Any takers?

The githooks are not working fully, they seem to write new files, but does not change/delete old files.
Something in checkout -f master maybe?

No reason not to now that ais is non-private and therefore Travis is free.

This issue was created to keep #25 clean. Please don't take this to mean that we're open sourcing the app, it's just a place to discuss what happens if we do.

@mictab on what we want from the license (from #25 (comment)):

If we're going to open source our code, we must add a restrictive license so that others cannot use our code. But even then we have a problem: how can we be sure that no one uses it? They can just hide their code in their back ends.

Nginx is already configured as a remote proxy, so this should be somewhat trivial, a good project for a code night perhaps. Letsencrypt is free, so that's nice. Also setup automatic renewal, since the certs only last 90 days.

It would be nice if there was a short explanation of the project at the top of the README, to make it easier for newcomers to get up to speed :) Just off the top of my head:

• What does "ais" stand for?
• What does it do? What is the scope of the project?
• Is there a link to a production server where I can see it "in action"?

Yeah... probably a good thing to do after all the discussions about other universities.

Should we use the github wiki pages for documentation? I was updating the readme, adding a proper "getting started" and i think it would be better off as its own github wiki page. As there are none yet i dont know if we want to use it. Any opinions?

Looks bleeding eyes crazy for the moment. How could this happen? :'D

https://github.com/armada-ths/ais/blob/master/templates/events/event_list.html

Hi. The mobile apps will need the url to an endpoint where we can get information about banquet placement. Ideally, we'd also be able to get some other information about the people as well, e.g. LinkedIn profile link. The URL to the image of the banquet map will also be needed somewhere.

Let's try to keep the code PEP8 :-)

The repo's kind of hard to navigate now (especially if you haven't worked with Django before) so I thought it would benefit everyone if we made the layout more logical. There's an SO answer suggesting something like this that I think would work:

Overview

docs/
config/
misc/
src/
static/
templates/
tests/
.gitignore
README.md
requirements.txt
Vagrantfile

Details

docs/
config/
  development/
    django/
      settings.py
    vagrant/
      provision.sh
      up.sh
  production/
    django/
      settings.py
      wsgi.py
    git/
      post-receive
    uwsgi/
      ais_uwsgi.ini
      restart_uwsgi_server.sh
      uwsgi_params
    nginx/
      ais_nginx.conf
    run_dev_server.sh
    update.sh
misc/
  banquet_placement/
  banquet_sms/
src/
  apps/
    companies/
    events/
    fair/
    locations/
    people/
    recruitment/
  urls.py
static/
templates/
tests/
.gitignore
README.md
requirements.txt
Vagrantfile

Does anyone have any objections to this? @walaro the deploy scripts will have to be tweaked but it shouldn't be too much work :)

And fix time settings, so that date time output is consistent

So after today's discussions I thought it would be a good idea for us to try and formalise what the Armada API should look like. My idea was that we discuss in the issue as normal and make edits to this first post if we agree on something, that way there's always a summary at the top of the issue. Which is nice :)

Summary

Endpoints:
GET /exhibitors
GET /exhibitors/:id

People

TODO

Events

TODO

Exhibitors

"Exhibitors" are equivalent to "companies" in the old API.

List organisations

List all organisations in AIS. Organisations are returned in shortened form.

GET /orgs

Response

[  
  {  
    "id":1,
    "name":"Acme corporation",
    "slogan":"A brighter past, a future tomorrow",
    "short_bio":"Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam fringilla facilisis metus. Nunc quam dui, lobortis id dapibus vel, ultricies eget ex.",
    "logo_url":"https://ais.armada.nu/images/GlaHquq0.png"
  }
]

Get an organisation

Get a specific organisation in AIS. Should return everything needed to display a detailed view of the company.

GET /orgs/:id

Response

{  
  "id":1,
  "name":"Acme corporation",
  "slogan":"A brighter past, a future tomorrow",
  "bios":{  
    "short":"Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam fringilla facilisis metus. Nunc quam dui, lobortis id dapibus vel, ultricies eget ex.",
    "long":"Donec fermentum mollis felis, bibendum tempor est condimentum ut. Fusce lobortis felis et mauris sodales, viverra accumsan diam auctor. Nunc ac vulputate felis. Aliquam tempus, ligula ut ornare blandit, lacus magna vehicula ligula, placerat cursus ex lacus eget neque. Proin tristique dui vel risus rutrum, vitae sagittis eros congue. Quisque sit amet diam dapibus, hendrerit urna a, hendrerit mi. Sed mollis condimentum nulla, nec scelerisque lacus. Maecenas varius quis urna vitae eleifend. Aenean congue nec mi id aliquam. Phasellus blandit tellus at justo ultricies, id commodo nibh feugiat. In felis lorem, vestibulum sed placerat quis, ultricies et felis."
  },
  "work":{  
    "fields":{  
      "Aerospace":true,
      "Architecture":false,
      ...
      "Wood-Processing Industry":true
    },
    "strategy":{  
      "Bleeding edge technology":true,
      "Challenging work":false,
      ...
      "Secure employment":false
    },
    "values":{  
      "Corporate social responsibility (CSR)":false,
      "Environmental liability":false,
      ...
      "Support for gender equality":true
    }
  },
  "stats":{  
    "countries":280,
    "continents":{  
      "Africa":true,
      "Asia":true,
      "Australia":true,
      "Europe":false,
      "North America":true,
      "South America":true
    },
    "employees":7200,
  },
  "images":{  
    "logo_url":"https://ais.armada.nu/images/GlaHquq0.png",
    "banner_url":"https://ais.armada.nu/images/dg6Hgu3P.png",
    "fair_location_url":"https://ais.armada.nu/images/Gn2HptvB.png",
  },
  "social":{  
    "homepage":"http://acme.co",
    "facebook":"https://www.facebook.com/acmeco",
    "twitter":"https://twitter.com/acmeco",
    "linkedin":"https://www.linkedin.com/in/acmeco"
  }
}

• Caching should be enabled for all static assets.
• Gzip should be enabled for everything.

This is easy to do in the nginx configuration file.

Delete http://anmalan.armada.nu/ please.
http://register.armada.nu/ exists and should be the default.

The exhibitor list for the new website will look a lot like the quick list in the current website from last year. It would still be nice to have small icons for all the exhibitors since it's easier to skim through the page and find the companies you are interested in and also we don't want to load the full size logo for every list item.
Something like 128x128 pixels would be nice!

The /companies and /events endpoints follow the format:
{
companies: [...]
}

In the next version of the api can we just get the JSON array directly without this wrapper?

It's probably a good idea to agree on some design guidelines so we don't end up with different frameworks/layouts/colour schemes for each page in AIS, especially if we'll all be working on separate parts of the system 👌

Decided

• Responsive design is a requirement
• Bootstrap all the things
• Business logic should be Django-first with as little as possible done client-side. Quote @walaro :

You can use javascript where ever you want (.. within reason ..), but as I said, the logic is done on the backend. Examples:

• You are filling out a form, Javascript can be used to check the input and inform the user of potential problems. But you still need to do all the checks on the backend as well, and if javascript is not active, you still need to be able to submit is as usual, the only difference being that you dont get the helpful hints.
• You are doing a date selector, to help the user, you make a useful widget that lets them click to enter a date, instead of writing it in in the ISO 8601 date format in text. But again, if javascript is not active, the user still needs to be able to enter a date.

• Don't add extra dependencies unless there's a compelling reason to do so.
• Do add extra dependencies if there's a compelling reason to do so. Example: Date widgets.
• The art directors might give input later on in the process, just keep it clean for the time being though.
• Update this when/if we decide more stuff.

Undecided

• Add more stuff here.

Use Djangos built in testing tools

Automate the way of fetching contact information in Initial Registration and Complete Registration

Mind if I remove the stale branches? :) Specifically:

• develop
• issues
• companies
• events
• banquett

Given the importance of imagery in the frontend clients, I really think we should invest time into re-thinking how pictures are handled and served in the api. I've therefore put together this list of features. I've ranked in order of how important I think the features are (Most important first, least important last)

• Better Image compression and sizing. Maybe the ability to specify webp formats (although I realize that this would probably only be useful on android and in chrome)
• Smaller logos #32.
• Sending a hex color code along with each image to be used as a placeholder when it loads.
• Remove logo_square_url.
• Sending the height and width of the image so that space can be allocated before it is loaded
• Ability to request smaller or more compressed images.

In the old system the urls look like:
http://niwen.armada.nu/fairs/armada2016
http://niwen.armada.nu/fairs/armada2015

This makes it possible to switch between different fairs.

Multiple tests are failing when running ./manage.py test.

Travis CI is set up, so if we sort every one of these out we can hopefully have a nice setup in the future! :)

Change the structure of the script to use a command line argument or to read password from stdin, then change the password.