What's Next! about rotalabutterfly HOT 254 CLOSED

Well... why don't we get started by introducing ourselves and respective skill-sets? I'll go first...

My name is Jennifer... I am a planted tank hobbyist and front end developer. I am proficient in HTML, CSS, Sass and pretty good with Javascript & PHP. I work on a Symfony based project during my day job but have no preference how you all want to handle the back end as I am pretty flexible although if you go Ruby it will take me a bit to get up to speed.

That's.... me :)

from rotalabutterfly.

Oh... and I've worked before with HighCharts, Charts.js and Google Charts api... so I'm ready to plot stuff out all pretty like.

from rotalabutterfly.

Hi Jennifer :) Jason here.

I'm more of a admin with a server (http://rotalabutterfly.com) for a few aquarium related websites.. www.barrreport.com being one of them.

Along with helping run this project, I can help by getting feedback from the users of rotalabutterfly.. What works, what needs changing, new features if any.. Etc.

Thanks :)

from rotalabutterfly.

I think we should stay with a more friendly language as mentioned php, javascript and SQL if its even needed?

Moving away from ruby?

from rotalabutterfly.

For anyone that is not apart of the development team but would like to have your say you are more than welcome to join the conversation at

http://www.barrreport.com/forum/barr-report/aquatic-plant-fertilization/225720-a-new-nutrient-calculator

Thanks :)

from rotalabutterfly.

Do we have an index of the old site plotted out anywhere? Its been years since I used it and I don't remember things like:

• how many different interfaces were there?
• how many and which calculators were there?
• how was the data output?

from rotalabutterfly.

Hi Jennifer and Jason, I am Fabrizio. I met Jason on the barrreport, I am a passionate planted aquarium lover, as well as a web programmer. My specialities are PHP, MySQL, JavaScript, jQuery, CSS and HTML (Perl also, but nowadays is outdated). I have also good knowledge of basic system management and configurations on Linux, but, I say it right away, I don't know Ruby at all!

Jennifer, if you feel confident working on the UI, I could take care of the more mere backend (PHP and MySQL). Any more people interested in jumping on the wagon?

from rotalabutterfly.

Welcome Fab great to see you here :)

from rotalabutterfly.

Hi Jennifer

Most of the answers you need can be found here

https://github.com/kisanjong/yet-another-nutrient-calculator/tree/master/constants

The best way to see what's going on is to use the running code here

http://yanc.rotalabutterfly.com

from rotalabutterfly.

Thanks Jason, glad to be here!

I think the best and easy way to go would be to establish a nice HTML interface (Jennifer?), and interface it to the back end via AJAX with jQuery (very easy to do). That would give high responsiveness, similarly to Wet's calculator. I could work on the back end interfaced via AJAX. I can help with jQuery if needed. jQuery could also help us to create a very responsive interface (jQuery UI is very cool!).

Just my ideas to start, in some way :)

from rotalabutterfly.

The constants at:
https://github.com/kisanjong/yet-another-nutrient-calculator/tree/master/constants

Can be easily put into a MySQL database for retrieval via PHP. That's the easiest part :)

from rotalabutterfly.

The constants are great news that will save a lot of time :)

In the back end can we add a admin interface so new products can be added with ease?, it does not need to be anything special just basic with name and contents fields I.e. fe % etc

Fab your plan sounds good to me :)

Should the layout stay the same? Left side calculate, right side result?

Thanks :)

from rotalabutterfly.

That could be a way to go... I have been wanting to work with React.js though, I can still make Ajax calls to the database or API with React - thoughts?

Either way - I like to plan things out beforehand. I will sit down this weekend and draw up some super basic wireframes/flows we can review before I jump into code. Sound good?

from rotalabutterfly.

Also, Hi Fabrizio! Welcome to the party :)

from rotalabutterfly.

Question - how/where do we handle the mathematics & calculations?

from rotalabutterfly.

Hi Jennifer! React sounds good to me, I have never heard of it, but if you are familiar with it, that's ok with me. I was thinking at jQuery because it also could help us with the UI (possible sliders, graphics, etc) and because it is probably the most known and popular JS library out there. So, anyone in the future can easily put his hands on that. Just my 2 cents!

I think the best way to handle mathematics would be via PHP with AJAX calls. I have already done several projects that way, and works great.

To Jason: Yes, I like the idea to keep the old interface structure, it is intuitive and people are already used to it. And of course, we can easily make a back end interface (sort of "Control Panel" or whatever). That's easy!

from rotalabutterfly.

I'm glad to hear that you want to handle the mathematics with PHP - I feel wholly unqualified to be in charge of that part :)

React is fairly new-ish - it was is a framework Facebook has been developing for the past several years so its surprisingly robust. I'm going to give it a go for this project and see how it does. I'll probably use elements from Bootstrap for the interface itself.

Other questions:

1. to clarify: we're building the calcs at yanc.rotalabutterfly.com as well as dropcheck.rotalabutterfly.com and glut.rotalabutterfly.com correct? Perhaps we should focus first on getting yanc.rotalabutterfly.com working and then move on to the other two, releasing them as we go.

2. What kind of git workflow do we want to use? All contribute directly to the repo or pull forks and then contrib via pull request?

from rotalabutterfly.

Ok Jennifer, I see your point, and that would be ok for me (despite I won't be able to put easily my hands on your code later on, just because I don't know that framework at all). So that I'd leave to you anything interface-side (I hope those frameworks are enough powerful on that side). Let's see what Jason says about that.

I am ok with point 1. And I leave point 2 to Jason's decision.

I am wondering if there will be any more contributors here, because that way we could have more input about all this.

Thanks!

from rotalabutterfly.

RE: Bootstrap... I'm planning to 'wrap' it in this theme https://bootswatch.com/sandstone/... its nice and warm and I like the green navbar. Reminds me of a planted tank.

As far as react.js being powerful I'm sure it will be fine since from a technical standpoint we're not doing terribly much, we don't need a full MVC framework, just some state-based interface jazz to make it interactive - and that's exactly what react was designed for :)

from rotalabutterfly.

@ravenwilde

our first point of action is yanc. as this is the main feature the users are after then once this is completed it would be great to update the other features as extra features, along with maybe some new ones.

I'm happy to use whatever language you guys feel happy with as long as it does what is required and new features can be added to that at a later date.

Bootwatch is a nice looking theme if Fab is happy to use that then I am.

With bootwatch can we have a responsive theme for desktop and mobile devices?

As different people are creating different parts of this project what method of github would you recommend?

Thanks :)

from rotalabutterfly.

@fablau

Im working on trying to get more involved in this project as I agree the more input the better.

We need to have visual as well as text based results output from the calculator/s.. Text and Charts etc.

from rotalabutterfly.

We also need language files that can be selected by users that speak different languages.. English, French, German, Japanese etc..

from rotalabutterfly.

Save results as PDF, Printable results?

from rotalabutterfly.

I am ok with that Jennifer and Jason! We can everything you like once we have PHP, MySQL and AJAX. Ready to go!

from rotalabutterfly.

• Mobile friendly - Yes! Everything I design these days is mobile first, responsive. So we will have one site/interface that can be used easily on any device.
• Charts and Graphs, no problem - I believe Flores used the HighCharts library to achieve this and I have no problem continuing to do so as I've used it before and like the results.
• PDF, printable results we can probably also work out - at the VERY least for the first launch I will include a print css file that will make the site and results printable. Later on we might be able to work out some kind of PDF generator.

So.... workflow for Git- I suggest that we establish an agreed upon workflow prior to starting anything. I can come up with a proposed flow if you like, just not this second because its Friday and I am about to kick back for the evening... I have a rough idea of what we should probably do but I want to look around at some recommended workflows to run by you guys first.

So far this all sounds great though - check back with you both tomorrow.

from rotalabutterfly.

Sounds like a good plan to me Jennifer :)

Please go ahead with the workflow I'm sure me and Fab will be more than happy with it :)

Any extra features will happen over time for now it's about getting the main calculator running and tested by experienced users of the original yanc.

Enjoy you evening Jennifer and thanks for your time in making this work its greatly appreciated 👍

from rotalabutterfly.

I lied... or rather, we only had one episode of our current tv show left in our queue ;)

Here is the workflow I'd like for us to try and use: http://nvie.com/posts/a-successful-git-branching-model/

Especially pay attention to git merge --no-ff when it pops up - we've had a lot of problems crop up where people haven't been using the --no-ff... it makes this very difficult to untangle if/when something goes wrong.

Question for Fabrizio - as far as PHP goes - are you planning on using a framework, or just writing the app from scratch? Either is cool, I'm just curious.

from rotalabutterfly.

That was quick :) Sounds good Jennifer and as your use to github I'm sure it's the way to go :)

It also makes sense not merging finished features until they are tested.

Obviously developers will use local servers to work but I will setup a new subdomain on rotalabutterfly to test any code before moving it to its final domain.

from rotalabutterfly.

I've updated the homepage of http://rotalabutterfly.com with some info about this project, hopefully it will bring in some more volunteers and ideas.

from rotalabutterfly.

Sounds good Jennifer, I like what you are describing for the UI.

Frankly this is the first time I am using Git, therefore I'll try to be careful and read through the documentation as much as I can. I was reading at the link below, and looks like that performing a "Merging Pull Request" equals to a "merge --no-ff":

https://help.github.com/articles/merging-a-pull-request/

Is that correct? I am trying to understand that because I'd use the Mac client (if possible) to speed up everything on my side. It looks pretty simple to use. But I don't want to be cause of messing up the code once I want to commit any changes to it!

To answer your question about PHP, I usually code from scratch by using my own libraries. And for this kind of project, which at the end is pretty simple, that shouldn't be a problem.

I plan to create a "config.php" script which will have to be run first from the administrator to configure MySQL and other basic stuff, as well as load all the compounds, language and other constants from static files into MySQL for better management later. By doing that, the package will be ready to use "out of the box". Your thoughts on that?

To Jason: cool to know about the testing subdomain. At due time, would be cool to have FTP access to that (additional SSH access would help even further).

And I like the updated homepage at rotalabutterfly.com, hopefully more people will be able to help to speed up the process. I'll try to work as much as I can, but as I told Jason, I'll have to deal with daily life obligations, trying to best contribute to this project.

Last comment: Jennifer, when you are ready, please start creating the first branch on GitHub so we can start working. You are more familiar with that than me, therefore I'd leave that to you :)

Thanks!

from rotalabutterfly.

Pull Requests:

So that is similar-ish to what the article was talking about. What you do in the instance of a pull request style workflow would be:

• create and check out a new feature branch - branch it off of dev
• work on that on your local
• then, rather than merging that feature branch back into dev directly, you would push your feature branch up to github
• once its up on github you would follow those instructions (the ones you linked to) to initiate a pull request
• usually then someone else in the project would review your code (for potential merge conflicts or, depending on the project, code standards) and then complete the pull/merge.

Given that our project is fairly small and, at this time, there are only three of us and our roles are pretty clearly defined, we can probably forgo pull requests for the time being. Therefore, as per the workflow I linked to yesterday, we would do something more like....

• clone a copy of dev onto your local
• create and check out a new feature branch - branch it off of dev
• work on that on your local
• when you're done with your feature branch merge it back into your local copy of dev with merge --no-ff... test it, etc and then when satisfied, push your copy of dev back up to origin on github

I can manage merges from dev to master and then once master is up to date, Jason (or both of you, however you want to work that out) can manage the deploy to the dev or public servers. EDIT: however you manage deploy is totally up to you - I don't really need to be a part of that process at all.

If the project grows and begins to take on new people we can instate pull requests as part of the workflow in order to keep things organized, but right now with the three of us and our well defined roles I think we should be okay.

Also, feel free to bother me with any other git questions you have - it takes a while to get a handle on if you've never used before and its totally fine if you use a gui or client on your end to manage things.

The only thing I'm going to be really particular about is that everyone please use the merge --no-ff in order to roll all your development commits into one when it hits dev. Also write clear and concise commit messages. There are some people at my day job who just can't seem to get a handle on that part and when something goes wrong its beyond insane to sort out :)

EDIT: Actually, wait... I think we may need to do pull requests from forked repos because we're not all members of the same organization. Let me think a bit and get back to you....

See... I use Github daily at work, but we're all members of a Github 'organization' (which I did not set up) so we can all commit directly to the main repo... let me see if that is still true for us without the 'organization' (which we may have to pay for).

from rotalabutterfly.

I plan to create a "config.php" script which will have to be run first from the administrator to configure MySQL and other basic stuff, as well as load all the compounds, language and other constants from static files into MySQL for better management later. By doing that, the package will be ready to use "out of the box". Your thoughts on that?

Sure, however you want to handle your end is fine by me - I don't care as long as there is something for me to hit with AJAX requests that will return JSON :)

from rotalabutterfly.

Okay... I think I have it figured out.... Jason, you need to add us both to the project as collaborators: https://help.github.com/articles/adding-collaborators-to-a-personal-repository/

from rotalabutterfly.

Both added as collaboratiors, thanks for the tip Jennifer :)

New sub domain has been setup for our testing once we are at that stage.

I have to say I'm already impressed with what we have discussed already the plan seems to be coming together 👍

Thanks :)

from rotalabutterfly.

Thank you Jennifer for the clear explanation, your help is greatly appreciated! I am a real beginner here on Git. I'd really like to be able to use the GUI, but I need to figure out if the merging is done with the "--no-ff" option, otherwise I'll use the command line... I'll try to play with that a little of my own.

As for my own PHP development side, sounds good! No problem to handle JSON calls and responses.

Thank you also to Jason for his last update. I'll start putting down something in the coming days. This weekend I am a little messed-up, but maybe I'll find some time to start with the basics. I'll be back!

from rotalabutterfly.

Hmmm... You'll have to read the documentation for whatever GUI it is you're using in order to figure out how to make things work - which client are you using?

from rotalabutterfly.

Created the dev branch, btw... feel free to clone it to your own repos and branch your features off of it.

from rotalabutterfly.

Jennifer, I'd like to use this:

https://mac.github.com/

And I see the new dev branch. I'll try what you are suggesting. Thanks.

from rotalabutterfly.

Hi, I was following the discussion at https://github.com/flores/yet-another-nutrient-calculator/
I am a software developer and have experience with CSS and jQuery as well as PHP/Laravel and Windows Phone development (if we ever want to build an app).

I can help with anything that it's needed and with translations to Portuguese.
I'm happy to see the project back alive.
Cheers!

from rotalabutterfly.

Hi! Welcome to the discussion. At this moment, I don't really need any help with the Front end aspect of the project, but you might want to talk to Fabrizio about back end/PHP

from rotalabutterfly.

Hi Diogolo and welcome. I am in the process of putting down the basic of the back-end. If you like, I could get in touch with you as soon as I understand what I can handle in the coming days and where we are headed. Please, let's stay in touch. Thanks!

from rotalabutterfly.

Hi Diogolo welcome and thanks for your interest :)

I'll leave Fab and Jennifer to allocate the front and back end tasks.

As this will be a multi language application your translations to Portuguese would be great, once we have a working English version we will release a language template that can be used to translate the app to other languages. So far I have volunteers to translate it to French, Czech and now Portuguese :)

Fab and Jennifer can I confirm the front end will pull data from a selected language? Similar to Flores yml files @ https://github.com/flores/yet-another-nutrient-calculator/tree/master/i18n

Thanks :)

from rotalabutterfly.

https://github.com/flores/yet-another-nutrient-calculator/blob/master/i18n/en.yml

from rotalabutterfly.

Fab and Jennifer can I confirm the front end will pull data from a selected language? Similar to Flores yml files @ https://github.com/flores/yet-another-nutrient-calculator/tree/master/i18n

Yep - I am currently working on an interface that handles selected languages.

from rotalabutterfly.

Yes Jason, I am sure Jennifer can confirm we can do that pretty easily. Also, if needed, keep in mind I am also Italian, therefore I can help with that side of the language as well :)

from rotalabutterfly.

Status Update: As of last night I've got react.js generating most of the form, going to finish that up tonight or tomorrow depending on life.
After that, I'm going to focus on the state changes and interactions that adjust the form prior to submission and then I will get it ready to make AJAX calls.
Maybe 1 - 2 weeks (I'm being generous and padding my time, because, life) and it will be ready to talk to whatever back end there is.

from rotalabutterfly.

Sounds great Jennifer! I am working as much as I can on setting up the basic configuration script which will create and populate the basic database. Once that's done, I'll be ready to work on AJAX calls.

from rotalabutterfly.

No rush - I'm trying to do a little each night but I've also got other things going on.

from rotalabutterfly.

Likewise!! No worries :)

from rotalabutterfly.

Great news and progress :) 👍

Where are the languages going to be called from?

File or database? Yaml? Sql?

Thanks :)

from rotalabutterfly.

Maybe Jennifer should decide that since she's taking care of the front end. I'd personally put language texts in MySQL, and then render the page(s) with a PHP template that fills text according to the chosen language.

from rotalabutterfly.

If we go SQL is it possible to add something to the administration control panel? Or is this to much work.

Add language..

Language: Italian

English text >> specific language value

element: Elemento
ppm: ppm
degree: grado
us_gal: Galloni US
imp_gal: Galloni UK

Thanks :)

from rotalabutterfly.

Maybe Jennifer should decide that since she's taking care of the front end. I'd personally put language texts in MySQL, and then render the page(s) with a PHP template that fills text according to the chosen language.

This is fine with me. As far as my part goes, this is how I envisioned my ajax calls working:

• On page load (default view with English as the default language) I would do an AJAX call for the English language entries and all the data I need to fill out the select dropdowns on the form
• If another language is selected then I would do another AJAX call for that language and the data for the forms, and this would happen any time a language is selected

Other than those two instances, the only other time I would need to talk to the server would be on form submit/process the returned values into the results graph.

from rotalabutterfly.

Brilliant :) thanks Jennifer 👍

from rotalabutterfly.

Isn't creating a MySQL database an overkill?
PHP (or even just JS) + JSON would be much easier to simply put in a new server without needing to configure anything.

from rotalabutterfly.

To be honest, yes it probably is... I can pull from JSON files with no problem.

Unless of course we want to build an Admin GUI/CMS that allows for non-programmers to update or add new data, which, I think was something that Jason requested.

from rotalabutterfly.

I'm happy with either choice but a admin GUI for me is a positive thing when adding new data, constants, languages etc.

from rotalabutterfly.

Side Note: This might be a better process for you when merging feature branches in as a single commit:

# Switch to the master branch and make sure you are up to date.
git checkout master
git fetch # this may be necessary (depending on your git config) to receive updates on origin/master
git pull

# Merge the feature branch into the master branch.
git merge feature_branch

# Reset the master branch to origin's state.
git reset origin/master

# Git now considers all changes as unstaged changes.
# We can add these changes as one commit.
# Adding . will also add untracked files.
git add --all
git commit

from rotalabutterfly.

I opted for the MySQL solution because of its scalability power... what if you want to "scale" the system in the future to include more data, or more compounds, or whatever? That way the DB system is already in place, and we can play with that much more efficiently. But of course if we deal with simple files, that is probably "faster" to update manually by anyone and no panels are necessary.

If everyone think using simple files is the way to go, I am ok with that, I can work that way instead. Actually that will require less work from my part! Please, let me know your thoughts on that.

Finally, thank you Jennifer for the suggest GIT process, I'll follow that.

from rotalabutterfly.

I don't think that scalability is the problem with JSON files.
Even if you have hundreds or thousands of different components, it will be parsed 'instantaneously'.
If you go though the route of having an admin interface to add/remove components, a proper database would be the way to go.
If all you want to do is read the components (and add them sporadically manually), JSON would be easier to implement and to setup in a new server.

from rotalabutterfly.

Good point Diogorolo (is that your name?), I agree with you. Let's do that way then, much easier for me as well.

I see the original files created by Wet are in YAML format, therefore we can simply parse those files with the YML parser:

http://php.net/manual/en/function.yaml-parse.php

What do you think? I don't think we need to convert those in JSON... we can keep that format if we want to, it is probably easier to edit than JSON with a simple text editor. Thoughts?

from rotalabutterfly.

Sorry Diogo, I found out right now your name is Diogo. Nice to know that. :)

from rotalabutterfly.

No problem, my first name is Diogo and last name is Rolo, therefore the username is diogorolo =P
So far I'm just giving some suggestions and trying to understand where the project is headed.
My main point is: If the admin interface is not to be implemented, I think a MySQL database would be overkill and we should opt for a YAML files instead.

from rotalabutterfly.

I agree with you Diogo! I am thinking if you could help in some way, seen that we can put MySQL aside now... I mean, the work is going to be reduced a big deal (thank you for pointing that out indeed!), the work will mostly focus on the calculations of the results to be given back to Jennifer's JS interface in JSON format.

I am just thinking aloud: are you familiar with Ruby? If so, we could actually convert what Wet wrote in Ruby into PHP... I am not familiar with Ruby, but I have looked at the original Wet's source files and looks pretty straight forward anyway. Once we have converted that, we could tweak it as we like.

I wanted just to know how's your knowledge with Ruby, so that potentially we could split some part of the work there.

Thanks!

Fab.

from rotalabutterfly.

Oh, by the way, I sign my messages with "Fab" but my name is "Fabrizio" :)

from rotalabutterfly.

Looking at wets yaml files it certainly is not a problem for me to update them or add to them if needed, also most languages, constants are already done for us? That's a lot of work saved as we can just add wets files to this project?

As I said I'm happy either way and its certainly makes thing easier and faster for you guys.

The admin GUI was just an idea.

Thanks :)

from rotalabutterfly.

Yes Jason, after analyzing original Wet's files in detail, that's a lot of saved work indeed. We can use the exact same .yml files for compounds, products, etc, and languages... and I could also actually translate Ruby's calculations into PHP pretty easily (I think), and then tweak the algorithms as we like. I'll jump into making the basic functions for all this. I'll keep you posted. I don't think it will take long.

from rotalabutterfly.

Brilliant :)

So its OK for me to upload wets files to the dev of this repo?

To confirm

Languages

https://github.com/flores/yet-another-nutrient-calculator/tree/master/i18n

Constants

https://github.com/flores/yet-another-nutrient-calculator/tree/master/constants

Thanks :)

from rotalabutterfly.

Also if we are using the yaml files as they are I can go ahead and add newer products that are not a part of wets calculator I.e jbl proscape range etc..

The language files will need tweaking to suit the new app? Once I know what English words/sentences will be used.

from rotalabutterfly.

Jason, about adding files to the repository, you can certainly do that, despite I will use my own files in my own directory for now. Later one we can link to those maybe... I have no idea how though! I am not GIT expert, Jennifer maybe will help with that. :)

As for adding new compounds, sure, go ahead! I will take those updated files.

I am currently struggling with the installation of the YAML PHP PECL extension on my system for testing purposes and to be able to read those files easy-and-fast with PHP, but looks like there are some missing resources on the source servers at http://debian.osuosl.org... figuring that out right now... crazy!

from rotalabutterfly.

I'll rewrite the yaml files here using the info from wets versions while updating them :)

I use centOS here

from rotalabutterfly.

Should we keep the language folder as i18n “internationalization" or?

And the same for the constants folder?

Thanks :)

from rotalabutterfly.

A quick research show me that the language file .cs is no longer valid?

Quote from wiki..

.cs was for several years the country code top-level domain (ccTLD) for Czechoslovakia. However, the country split into the Czech Republic and Slovakia in 1993, and the two new countries were soon assigned their own ccTLDs: .cz and .sk respectively. The use of .cs was gradually phased out, and the ccTLD was deleted some time around January 1995.

So some files will need updating to for example .cz ?

Ill also check the other languages are valid.

Just checking / confirming things before I go ahead

Thanks :)

from rotalabutterfly.

I'd keep the same file names, but of course I'd update those you mentioned as needed. Thanks Jason.

from rotalabutterfly.

Tomorrow I'll start working on the current languages and constants then update when needed.

Thanks :)

from rotalabutterfly.

OK I've add the constants folder and i18n folder ( English and template.yml only for now until we have confirmed the English wording for the new app then i will move on to the other languages.

from rotalabutterfly.

Jennifer / Fab if im doing anything wrong on the git hub part please say :)
im adding to dev first? then master once its at final release.

from rotalabutterfly.

I think you did it right, Jennifer can confirm that :)

from rotalabutterfly.

Yep, you're good 👍

from rotalabutterfly.

👍 thanks

from rotalabutterfly.

Concerning the License, should it be published under MIT so anyone can use?
https://en.wikipedia.org/wiki/MIT_License
Currently, no license is selected.

from rotalabutterfly.

Diogo, I think we'll definitively do it under the MIT license. Jason can answer that.

UPDATE: I have translated the 3 simple functions inside conversions.rb into PHP functions, that was very easy. I have also put down the basic files to load the libraries (constants) from .yml files into simple PHP arrays.

Now, I'll try to translate into PHP most of the contents of the nutes.rb file which is the actual main program of Wet's work. I'll try to recycle as much code as possible from the original calculator, and I'll keep you posted on that.

In any case, I think to be ready to start with the AJAX interface. I'll wait for Jennifer for that.

from rotalabutterfly.

Hi Diogo, no licence set yet until I've spoke in detail with the team, but have been looking.

http://choosealicense.com/

We will decide once the project is at release stage.

On another note keeping the calculator running at one place allows it to stay updated? Unlike rota.la Fab and Jennifer will have access to the hosting side of the site so if for any reason I'm away one of them will still have access preventing the same thing happening again that has happened with rota.la

from rotalabutterfly.

Great progress Fab :)

A member of the Barr report nicpapa is also kindly researching new products and posting the elements/compound % of the products so far we have JBL proscape ferts and dennerle both are not apart of wets yanc.

Thanks :)

from rotalabutterfly.

A member of the Barr report nicpapa is also kindly researching new products and posting the elements/compound % of the products so far we have JBL proscape ferts and dennerle both are not apart of wets yanc.

Yes, I am following that thread Jason. Great stuff! :)

I'll give you an update on the progress soon.

from rotalabutterfly.

Update: I am pretty much half way of translating the original Wet's nutes.rb file into regular PHP. At the end it's a lot of fun because I am also learning some Ruby (!!!). Once I am done with this work, I will give Jennifer the input variables needed for the backend to work with AJAX calls.

Maybe I'll finish in the next 24-48 hours (gotta be busy with family and stuff this weekend)

Cheers...

from rotalabutterfly.

48hrs! I'm impressed :)

It's certainly coming together a lot faster than I expected.

Thanks :)

from rotalabutterfly.

Well, I think so, unless something unexpected should ever happen :)

I'll keep you posted!!

from rotalabutterfly.

Jason, I have been able to convert the nutes.rb from Ruby to PHP, despite there are a couple of lines I am not 100% sure how they should behave, but I'll figure out as soon as I make a test with the correct inputs. Also, I have left out the bottom part of the script which takes care just of the graphics draw (Jennifer's front-end should take care of that.)

Now, I'd need to access Wet's live calculator to review all the inputs and make a simulation with the translated PHP script of my own, but I see the website is no longer reachable:

http://rotala.butterfly.com

Ideas?

from rotalabutterfly.

Just to give you guys an heads-up (mostly for Jennifer), here are the input variables extracted form Wet's Ruby implementation:

tank_vol
tank_units
source
round_to
compound
method
dose_units
dose_amount
target_amount
calc_for
premix
premix_method
premix_dose_units
premix_dose_amount
premix_target_amount
premix_calc_for
sol_volume
sol_dose

Those should be constructed in JSON in this way (just to give you an example):

{"source":"diy","tank_vol":"75","tank_units":"gal","compound":"KNO3",etc....}

But I need to map all of the above variables correctly, and as I said in my previous posting, I'd need to access the live calculator for testing. Reverse-engineering is not easy thing without the running live model! :)
Thanks!

from rotalabutterfly.

Ok, thanks to the web archive:

http://web.archive.org/web/20140209114431/http://rota.la/

I have mapped most of the above variables:

tank_vol ("My aquarium is" [tank volume])
tank_units (gal or L)
source ("using fertilizers" [diy or premixed])
round_to ("Round to digits past the decimal")
compound ("I am dosing with" [KNO3, etc.])
method ("using" [a solution or dry dosing])
dose_units ("and I am calculating for" [the result of my dose])
dose_amount ("I am adding" [dose])
target_amount ("My target is" [ppm])
calc_for ("and I am calculating for" [what dose to reach a target, etc])
premix ("I am dosing with" [ADA Bright K, etc.])
premix_method ??
premix_dose_units ("I am adding" [mL, tsp/caps, etc])
premix_dose_amount ([dosing amount])
premix_target_amount ("My target is" [ppm amount])
premix_calc_for ("and I am calculating for" [what dose to reach a target, ])
sol_volume ("My solution container is" [mL])
sol_dose ("and each dose is" [mL])

But still I'd need a working version of Wet's calculator to compare my results with his and be sure that my translation from Ruby to PHP works. I'll wait for you Jason... enjoy your Father's Day guys!

from rotalabutterfly.

Looking good Fab.

Concerning the URL you have a typo ;)

It's http://rotalabutterfly.com

And wets URL is http://yanc.rotalabutterfly.com

Thanks :)

from rotalabutterfly.

Once you and Jennifer are happy with the results we can add it to test.rotalabutterfly.com for some beta testers to confirm?

Also maybe a contact form page, can you add this to the front end please Jennifer?

https://github.com/pinceladasdaweb/Simple-PHP-Contact-Form

The form itself Needs to be translated to English and maybe change the design slightly to match your frontend design? The form works fine as I use it already on a site :)

One more thing is wet used lots of sub domains for all his apps I would like to stick with one domain for all of them except wets original yanc. as I'll keep that running as it is and the test. for testing.

Thanks :)

from rotalabutterfly.

Or your own contact form as you may already have a version in your code library :)

from rotalabutterfly.

Looking good Fab.

Concerning the URL you have a typo ;)

It's http://rotalabutterfly.com

And wets URL is http://yanc.rotalabutterfly.com

Thanks :)

Thank you Jason and sorry for the confusion! Yesterday must have been a little melted :)

I'll review the inputs above and define the missing one.

As for having a single domain, what other apps are you talking about?

from rotalabutterfly.

Ok, thanks to the live calculator I have figured out that the above 'premix_method' input variable is not used at all, and that should be the same of 'method'. Looks like Wet's nutes.rb had that defined input variable in error (or a typo?) in some way.

Ok, so the definitive input parameters (or variables) are:

tank_vol ("My aquarium is" [tank volume])
tank_units (gal or L)
source ("using fertilizers" [diy or premixed])
round_to ("Round to digits past the decimal")
compound ("I am dosing with" [KNO3, etc.])
method ("using" [a solution or dry dosing])
dose_units ("and I am calculating for" [the result of my dose])
dose_amount ("I am adding" [dose])
target_amount ("My target is" [ppm])
calc_for ("and I am calculating for" [what dose to reach a target, etc])
premix ("I am dosing with" [ADA Bright K, etc.])
premix_dose_units ("I am adding" [mL, tsp/caps, etc])
premix_dose_amount ([dosing amount])
premix_target_amount ("My target is" [ppm amount])
premix_calc_for ("and I am calculating for" [what dose to reach a target, ])
sol_volume ("My solution container is" [mL])
sol_dose ("and each dose is" [mL])

from rotalabutterfly.

I forgot to answer this:

Once you and Jennifer are happy with the results we can add it to test.rotalabutterfly.com for some beta testers to confirm?

Of course! That's absolutely needed!

from rotalabutterfly.

added a txt file that i will probably rename once we use it?, i thought having a glossary of terms for reference would be handy?

https://github.com/kisanjong/rotalabutterfly/blob/dev/glossary.txt

from rotalabutterfly.

As for having a single domain, what other apps are you talking about?

other apps as in Want to model long term effects of K dosing? i know a few have mentioned this to me.

drop checker..was this used by any body? along with any other apps from the original rota.la

from rotalabutterfly.

P.S i dont have a working copy of Want to model long term effects of K dosing..

from rotalabutterfly.