Stack and skills

[birdcolour]

After having a discussion with Fahran last week, we came to an approximate conclusion to what we will use in the stack, based on:
a) Things we think will make it easy for us,
b) Things we'd like to put on our CVs,
c) Alcohol.

Naturally if you have any preferences you'd like to add, please discuss below.

Web: Django + Postgres
Hosting: Google Cloud
Mobile apps: Try and wrap as much of the website as possible to avoid native development

It would also be helpful to know what languages/skills/general area of expertise contributors have or are willing to learn - if you could comment these below that would be fab.

[birdcolour]

Personally, my background is in data science, so Python is my go-to language. I'm learning JS and MS SQL/SSIS on the job at the moment, though I am perfectly happy to try anything that is not the Microsoft SQL stack because it is a right pain in the arse.

[smudgefarrier]

My CV: I developed powertab archive before it was forcefully closed down by MPAA. It was for sharing powertabs (guitar tabs) and had thousands of tabs and users (if not hundreds of thousands). That was back in 2005 when PHP and MySQL was all the rage. Then I got a real job doing C/C++ server side stuff professionally.

I haven't really looked into what the latest greatest stuff so I don't have an immediate useful opinion, I'll have a look around and see how they work. It is probably worth getting a shortlist and trying a few things out in each (prototype some ideas of what you want to do) to see what works best. From quickly reading around, I suggest looking at least at Flask too.

[lanky]

I'm all about the python, generally, with Django and Flask experience, can work with either. Jinja and cheetah templating. Have written REST APIs. Mostly into orchestration/automation these days though so occasionally a bit rusty. Some jQuery.

[fahran]

Hello :D

Late to the party. I am Fahran! I am mainly a Java dev, mainly REST-based Microservices with random skillpoints in DevOps, Cloud infrastructure, maybe some front end if you're lucky.

I would like to learn more Python. Python is cool, and it's eating data science, and I want to play.

I also offer random cat herding skills a la project organisation. Trello board backlog, anyone?

[smudgefarrier]

Oh yeah, I should share progress so far. I've taken python, flask, and google cloud's app engine and put this together http://doodle.ukejam.online/. I'm getting the guys in Belfast Uke Jam to trial it, I'm not happy with the technical structure of it so improving it before sharing it on github (otherwise it'll be a mess to collaborate on).

[smudgefarrier]

Google Cloud hosting looks to be very expensive option, the trial gives me a fair amount of credit, but in the 3 weeks or so of having a very basic app python app + postgres running, it would have charged me £48. Considering I'm expecting very little traffic there will be cheaper alternatives. I'll also look into whether that is something else that could be incorrectly racking up charges (but I think it is simply the 24/7 availability). Does anyone else have a similar or contradictory experience?

[lanky]

looks like @smudgefarrier is doing all the work :)

Anyway, I'm a contrary sort, so as I like to be difficult and I have an aversion to javascript (I actually don't know why, and I've used it before), I decided to play with python for the conversion process - I figured that python already has excellent Markdown support, so why not just extend it?

I'm also the songbook maintainer for the Karauke loons so I have additional requirements I'd like to be able to plug in:

• the ability to generate 'singers' versions in portrait for printing
• multi-column landscape for projection
  this means hiding chords and cleaning whitespace etc, possibly adding watermarks and footers and indexing (I see you already have this)

so my current musings are here...
https://github.com/lanky/ukebook-md

[smudgefarrier]

The reason for using javascript was to have the live previews in the browser, I was going to use python to run the javascript code on the server side to keep preview and server usage identical (when/if needed). I'm not quite sure how to reconcile the very different approaches.

Regarding the "Karauke loons", could you send me some examples of what you're after, I can't quite follow it from the description and a lot of it should be possible with css.

[lanky]

@smudgefarrier I was assuming it would be - me pursuing the python side was out of personal interest. I just thought I'd share :)
The work you've done is great - I couldn't have done it anyway and your experience of this dwarfs mine.

I agree, CSS is probably the best approach - I was thinking that way myself.

So, for karauke we use the same format that wednesdays does, but without chord diagrams, unless they're very unusual as quite frankly we should know them by now!

Singer's sheets don't need chords - that should be as simple as "display: none". They do require a little reflowing.

We also generate menu sheets for the current songlist.

For projection, we'd ideally degrade into 2 column side-by-side with appropriate scaling. We should be able to size to viewport really. Because it's been ODT -> PDF (or more recently DOC/DOCX then back to ODT to fix everything then to PDF :) ) we've stuck with standard paper sizes (A4) but for projection, PDF is arguably overkill. If we're never going to print it...

[smudgefarrier]

I think I get:

1. An option to hide the chords diagrams
2. Provide a landscape page layout, with 2 columns, this is actually a great idea for a layout on tablets.
3. Automatically scale previews to match a browser's viewport.
4. Standalone contents page.

[smudgefarrier]

@lanky, so I've done 1 & 2 of the above now.