New Version of the Calendar

Education
#1

As many of us have seen most of the development is a bit stalled and I get the sense that its because the codebase is in php-cake. While I’m familiar with php, cake is one of those things that gets in the way of development imho. It would be very easy on my part to take the current core functionality and migrate it over as a microservice to a more agile and well understood framework like flask, express, swagger.

However before I go taking that kind of endenver I want to make sure the rest of the membership can jump in and contribute as they feel fit. Let me know in the poll which web app stack you’ll like us to use going forward

  • Python Fask
  • NodeJS express
  • PHP cake
  • Ruby Padrino/Sinatra
  • Go

0 voters

(Deadline for the poll is the end of September where I’ll be discussing this further with @Team_Calendar and @Team_Education before bashing out features. )

#2

I’m trying to develop for it but there’s absolutely no support for it from an infrastructure side. Took a month to get the code merged in and it still hasn’t been deployed a month and a half later.

Alex is also trying to get deeper account integration with it. https://dallasmakerspace.org/wiki/Board_of_Directors_Meeting_20170825#Calendar_Software_revisions

I think it’s a waste to rewrite software, especially in a different language. 80% of the time the developer rewriting it burns out and the other 19% you end up with a product that lacks important features of the old one.

Somehow the body is too similar to my response in the other thread, Discourse please let me post omg

1 Like
#3

The minutes for that item might be of interest

I suggest that the answer/solution will be dependent upon what the board ends up doing. If they put the work on for contract, we (DMS) should provide the specification, which should include language and libraries that can be used.

1 Like
#4

4 posts were split to a new topic: Makerspace Coding Standards

#5

I voted for Python/Flask.

I believe Python is the way to go as far as the language. It is popular. It is a fairly easy language to get started using and there is a lot of interest among members to learn it.

I specifically chose not to use Brandon’s back end written in Go so that we do not have too many different languages in use.

A secondary choice would be to learn PHP and deal with Cake.

As for Flask, I am still undecided. I am learning it working on first the Voting/AD kiosk and then the storage kiosk. These apps do not need to be client/server and structuring them that way added unnecessary complications.

The calendar is client/server so some kind of framework of this type will be needed. Is Flask the best suited for what we need to do?

As for replacing the current system, I have mixed feelings. I have been in the business long enough to know that most programmers prefer to write new code than to maintain old. The current system is far from perfect, but it is much better than what we had and is working for the most part.

The danger in starting over is that any knowledge embodied in the old system may be lost and we wind up fixing the same bugs over again. So the major and first decision going forward is whether we fix what we have or build a new one. If we choose the latter, it is vital to document what we need the system to do, otherwise it will not magically happen.

2 Likes
#6

We should write up the user and admin needs first before determining the platform/environment.

Like choosing your rocket fuel before your mission. :wink:

6 Likes
#7

I ask that any solution we use be PHP-based (or at least easily pluggable into apache or nginx) and use our existing MySQL/MariaDB cluster on AWS.

My PHP ask is for clustering reasons - I can literally copy a VM and load balance them with a properly set-up application… I just ask the same be done for whatever you use.

3 Likes
#8

And to echo Brooks, it is probably wise not to have to run 20 different environments just for soup de’ jour.

3 Likes
#9

There are a thousand ways to skin a cat and I think focusing on the language before what actual improvements will be made is the wrong approach.

Little backstory on why its in PHP…becauase MM3 is in PHP and that is in PHP because MM2 was in PHP. The thought was that PHP is accessible. It’s not like the calendar is written in Assembly.

I have lost count of all the systems I have looked at but redoing the current system just so its in a different language with no improvement is ridiculous to me. If we were to redo/fix anything I would say lets focus on fixing the billing system. Combine the two.

If you want to do it in python take a look at what TXRX did. https://txrxlabs.org/ and its github
https://github.com/chriscauley/txrx.org

7 Likes
#10

I understand, and those same concerns is why I use docker and 12 factor app design for microservices.

#11

that’s part of the core here, most of everything else at the space is in Python and the majority of the membership uses python.

#12

thanks for the links. I’ll look them over but going over the concern of intergration of kill bill and calendar, that’s part of a concern of mine as well.

Currently the front end we have is tied into the php backend. I’m wanting to break that out as a single page app which hits a API gateway that would route to each micro service API we need, either calendar, billing/accounts, tools, auth, services, …

We’re wanting a bunch of tablet kiosks all over the space, some badge access systems, and over in another thread some are wanting mobile to work.

To do that setting up a smaller system which is easily developed by the majority not the few is the way to go. I know one can pickup php and build a broken app but the majority of resources for development is in python.

I don’t say this to debate for or against changing languages, just stating facts.

Now I do get that a lot are looking at this as an large undertaking and share their concerns. It’s something I always considered daily in project management and are application architecture.

I’d ask this question, if hypertheically one could start from scratch and have a dedicated development committee whom is available 24/7 to the membership build something that the membership could use. What would that app look like for MVP and what features are they wanting?

#13

I know there are some people that have done python stuff around the space but none of that is production. There was an attempt to change out the rfid system but it got hosed and wasn’t working for several weeks. That isn’t acceptable. Even by the poll now python is only 1 vote ahead of php. My concern is that all this work will be done and in a year we will be in same place.

That’s great but working with volunteers is completely different from telling people who are paid how to do something.

If we are going to do a soup to nuts re design there should be a focus on the issues on the backside that are truly broken. If a meeting gets set up for this I definitely wish to be there.

From what I have seen in kill bill it doesnt solve all the issues. How do you handle family accounts and such? Is MM3 still going to exist? still using AD as a master record?

I am not saying don’t do it but I have my concerns.

3 Likes
#14

All valid concerns. On the kill bill side, I’m working with Stan on the poc but agree there should be a design meeting on the calendar focused on addressing existing bugs in our current system(s) and defining business adjective goals.

Does Wednesday’s evening work for an 45 min meeting? It would cover initial addressed items and close with prioritizing listed as todo in Infrastructure Kanboard and Development Kanboard

#15

Can we do it on a weekend? I’d love to be a part of this.

3 Likes
#16

Could do a Saturday or mid-day Sunday.

All of @Team_Infrastructure would be on that invite Including Alex and yourself but its open to anyone that wants to attend.

1 Like
#17

I voted for PHP. I worked for a company who built a full fledged EMR (electronic medical record application) for 1000’s of users using PHP/Cake. It was MySql based. It was incredibly fast, which the docs loved, it was easy to support and it was used in many application environments so there were quite a few management tools available.

I also support developing requirements, use cases, storyboards, or whatever the method dejure is before selecting a programming language. @bscharff has another outstanding point that we need to look hard at the infrastructure and support questions as a key aspect of initiating a new development project. Lastly, @AlexRhodes’ points are also well made in that we have an investment in the existing implementation and his production concerns.

I agree that Python is popular and there are a lot of people at DMS who use it, especially in their projects, but I don’t think this is a reason to change development environments.

Like @Lampy said we need to define what we’re going to build before we pick the “rocket fuel” to launch it.

It is interesting how many DMS makers are also in the software engineering business. This should give us some great talent to draw upon.

4 Likes
#18

Python is popular and there are a lot of people at DMS who use it, especially in their projects, but I don’t think this is a reason to change development environments

Valid point and I get where you’re coming from but there’s a lot more to the matter than just “Python is popular”.

Just look over the build logs for makermanager and calendar. While a lot of those maybe best practice issues there’s several there which could have been prevented by a cleaner codebase with a smaller development footprint which was unit tested from the start. I suppose the argument there is more against a bloated mvc framework like cakephp than php itself though even python is easier to understand when written correctly from the start.

For example:

#19

This issue won’t be defined by language zealotry, or cake intolerance. As Walter’s posting of the agenda made clear, we’re looking at fixing the core infrastructure systems now. That’s when we need it, and that’s when we’re ready to act on it.

I truly appreciate the willingness to volunteer time writing code, and there are definitely places where it could be of real value (storage management?), but so sorry, our primary member management systems won’t be among those choices. The need to move is just too pressing to wait for volunteer development to finish. I’m just offering you my truthful opinion here. I can’t speak for the Board, but I will offer you a personal handicap of a vote to “wait and do volunteer development” , and feel pretty confident that a “no” vote would predominate. It would have nothing whatever to do with you, or your very laudable desire to contribute, its just the way things are right now.

I would suggest talking to the logistics folks and Bill. Brandon’s work on tickets was just a small taste of what a real system could do for logistics. And its a greenfield. An online extension request feature, ticket printing, expiry notifications, configurable ruleset, and the ability to set some slots as paid storage, or committee storage, RFID integration, etc etc.

2 Likes
#20

We should determine the spaces overall software needs. Broken into functional blocks such as public facing tools like the website and back-office blocks like calendar, MM3 etc. Then define the needed connections between them. Even then some blocks are big enough they would need to be subdivided into phases. This is too big to get done at one pass. At least we can define the interfaces or APIs between each.

6 Likes