What's Next!

[kisanjong]

Post created so we can all get together and discuss how we should go about this.

Your ideas and comments please.

Thanks :)

[fablau]

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.

[kisanjong]

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 :)

[ravenwilde]

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.

[kisanjong]

Brilliant :) thanks Jennifer :+1:

[diogorolo]

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.

[ravenwilde]

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.

[kisanjong]

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

[ravenwilde]

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

[fablau]

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.

[diogorolo]

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.

[fablau]

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?

[fablau]

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

[diogorolo]

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.

[fablau]

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.

[fablau]

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

[kisanjong]

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 :)

[fablau]

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.

[kisanjong]

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 :)

[kisanjong]

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.

[fablau]

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!

[kisanjong]

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

I use centOS here

[kisanjong]

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

And the same for the constants folder?

Thanks :)

[kisanjong]

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 :)

[fablau]

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

[kisanjong]

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

Thanks :)

[kisanjong]

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.

[kisanjong]

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.

[fablau]

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

[ravenwilde]

Yep, you're good :+1:

[kisanjong]

:+1: thanks

[diogorolo]

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.

[fablau]

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.

[kisanjong]

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

[kisanjong]

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 :)

[fablau]

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.

[fablau]

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...

[kisanjong]

48hrs! I'm impressed :)

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

Thanks :)

[fablau]

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

I'll keep you posted!!

[fablau]

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?

[fablau]

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!

[fablau]

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!

[kisanjong]

Looking good Fab.

Concerning the URL you have a typo ;)

It's http://rotalabutterfly.com

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

Thanks :)

[kisanjong]

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 :)

[kisanjong]

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

[fablau]

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?

[fablau]

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])

[fablau]

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!

[kisanjong]

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

[kisanjong]

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

[kisanjong]

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