IRC logs for #farmOS, 2016-10-14 (GMT)

2016-10-13
2016-10-15
TimeNickMessage
[20:14:45]* JustTB has quit (Quit: Leaving.)
[20:23:03]* kadaan is now known as kadaan_
[22:03:22]* kadaan_ is now known as kadaan
[22:50:37]* kadaan has quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
[02:37:29]* kadaan has joined #farmos
[04:10:40]* JustTB has joined #farmos
[04:29:28]* mstenta has quit (Ping timeout: 250 seconds)
[05:04:11]<kadaan>@mstenta Another one to consider a comparison against is: https://farmbrite.com
[05:07:34]<JustTB>btw. I would like to help, but at the moment I'm pretty full with the project here .. hopefully the next two weeks are more free.
[05:08:37]<JustTB>we still have farmos in mind ... and want to try that here ..
[05:09:09]<JustTB>to many people are coming and going at the moment
[05:10:12]<svenn>anything .com is freaking me out.
[05:10:32]<svenn>anything not self-hostable is freaking me out
[05:24:30]* kadaan has quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
[09:38:55]* Kadaan has joined #farmos
[11:48:57]* Kadaan has quit (Quit: Connection closed for inactivity)
[12:04:50]* kadaan has joined #farmos
[12:09:30]<kadaan>@svenn: No worries here about that. Just as long as I can get my data in and out in a generic way.
[12:11:10]<kadaan>@JustTB: If your Drupal experience is better than mine, you might be more help in the short term. I've been able to make a number of changes for the 7.x version, but the 8.x version is just not quite there enough for me to help. Maybe when @mstenta gets more time we can really get the move the 8.x focussed.
[12:13:27]* kadaan has quit (Quit: Textual IRC Client: www.textualapp.com)
[13:23:47]* mstenta has joined #farmos
[15:55:15]* kadaan has joined #farmos
[16:38:41]<mstenta>kadaan: hi!
[16:38:47]<kadaan>Hey
[16:38:47]<farmBOT>hello
[16:38:57]<kadaan>How's the farm hand doing?
[16:39:20]<mstenta>he's doing well! :-)
[16:39:23]<mstenta>eating now
[16:39:47]<mstenta>regarding COG Pro - I can't really speak to it - I haven't used that
[16:39:57]<mstenta>i've heard it tho - and FarmBrite
[16:40:16]<kadaan>They all look like drupal apps now...
[16:40:20]<mstenta>i guess the obvious difference is that farmOS is open source, you can host locally, and modify it yourself
[16:40:26]<kadaan>Can't tell for sure.
[16:40:40]<mstenta>hmm could be
[16:40:51]<kadaan>I really like that. As it means there is no data lock in.
[16:41:00]<mstenta>i remember looking at one that was using the same theme (Bootstrap)
[16:41:04]<mstenta>so it looked a lot like farmOS :-)
[16:41:36]<kadaan>COG Pro is in a lot of the farm magazines.
[16:41:42]<mstenta>re: farmOS 7.x-1.x vs 8.x-2.x - yea i understand that it's a tough time, especially since you're jumping in with a lot of interest in helping out
[16:41:47]<kadaan>For instance: Growing for Market.
[16:42:15]<mstenta>the way i see it - we should continue developing 7.x-1.x as long as we need to
[16:42:26]<mstenta>so i would love to keep you involved in those efforts if you're interested
[16:42:58]<mstenta>sure we'll need to redo for 8.x-2.x, but that's the same for everything
[16:43:11]<mstenta>and i would like to have some time for 8.x-2.x - i don't want to rush it
[16:43:17]<kadaan>Sure. I'd love to. Just want to be sure that we don't unnecessarily delay 8.x.
[16:43:18]<mstenta>because it is also an opportunity to rethink some things
[16:43:19]<kadaan>Make sense.
[16:43:31]<mstenta>yea definitely - it won't delay 8.x
[16:43:53]<kadaan>You should peak at COG Pro as it slates itself as tracking the info needed for Organic Certification.
[16:44:03]<mstenta>it would be great to talk through some of my ideas for 8.x with you also
[16:44:07]<mstenta>WHILE we continue working on 7.x
[16:44:15]<mstenta>to help validate some of the things i've been thinking
[16:44:17]<kadaan>That would be fine.
[16:44:29]<kadaan>I'm available most evenings or mornings.
[16:44:30]<mstenta>yea, do you have an account on COG? love to hear your thoughts
[16:44:42]<kadaan>They have a "free" trial account.
[16:44:49]<mstenta>cool - we should find a good pattern and keep the balls rolling
[16:45:10]<mstenta>one thing i've been thinking about...
[16:45:15]<kadaan>I don't really like the way COG Pro is styled like a notebook.
[16:45:26]<kadaan>https://cog-pro.com
[16:45:35]<kadaan>You can just login with the guest account that is pre-populated.
[16:46:07]<mstenta>oh yea - i remember looking at this a while back
[16:46:27]<mstenta>for what it's worth, my friend Dorn is using farmOS for his organic certification records in New Hampshire
[16:46:38]<mstenta>for veggies anyway
[16:47:10]<mstenta>i spent some time a while back pouring over the organic cert recordkeeping example forms that ATTRA provides
[16:47:13]<kadaan>How is he getting the data back out for the reports?
[16:47:31]<kadaan>Cool. From what I could tell most of the stuff needed is there.
[16:47:42]<kadaan>Just not the exports or reports.
[16:48:24]<mstenta>his certifying agent just wants PDFs, so he was able to "Print" the pages to PDF that they wanted
[16:48:33]<mstenta>along with some screenshots i think
[16:48:50]<kadaan>That is nice.
[16:48:54]<mstenta>the thing is... every certifying agency wants different things
[16:49:04]<mstenta>but if we can hit most of the common requirements, i think we'll be in good shape
[16:49:33]<mstenta>and over time, hopefully certifying agencies will start to recognize the farmOS formats, and allow them for recordkeeping more easily
[16:49:50]<mstenta>are you certified?
[16:50:53]<mstenta>one thing we should definitely talk about...
[16:50:57]<mstenta>is process
[16:51:01]<kadaan>Nope...
[16:51:09]<kadaan>We are just setting up our farm
[16:51:45]<mstenta>i was thinking about it in the car the other day... i think i'm going to write up a "farmOS Coding Standards" document that outlines generally HOW i go about developing, committing, etc - so that everyone can be on the same page and work similarly
[16:52:03]<mstenta>that will make it a lot easier for me to review and commit changes from others - if we're all following the same patterns
[16:52:21]<kadaan>That would be great.
[16:52:25]<mstenta>for example, as a first step farmOS follows all the same coding standards as drupal
[16:52:39]<mstenta>https://www.drupal.org/docs/develop/standards
[16:52:52]<mstenta>so we could also document some standard practices on top of that
[16:52:55]<kadaan>I'd rather not spin my wheels by having to keep changing the PRs to meet requirements I don't know about.
[16:52:58]<mstenta>it's all about project management :-)
[16:53:07]<mstenta>yea definitely - i wouldn't want that either
[16:53:22]<mstenta>oh - so i made some good progress on the docker thing the other night... at like 3am :-)
[16:53:44]<mstenta>once i get that finished, i'm going to get your changes pulled in to review them
[16:53:47]<mstenta>sorry it's been taking a while
[16:53:57]<mstenta>you jumped into this at a VERY busy time in my life haha :-)
[16:53:58]<kadaan>You are totally going to get it done because your kid won't let you sleep.
[16:54:04]<mstenta>haha
[16:54:14]<mstenta>yea i might work on it a bit now before dinner - he's asleep
[16:54:36]<kadaan>No problem. I looked at farmOS a while ago, but we weren't close to having our property then.
[16:54:40]<mstenta>i also have a Farmier user who wants to import their local SQL database into Farmier, though, so I gotta get that done too
[16:55:00]<mstenta>i'm just doing a manual SQL import for that one
[16:55:11]<mstenta>one-time thing to help them get up and running in Farmier
[16:55:15]<kadaan>Nice. Is there any easy way to import the SQL, or will you do it manually.
[16:55:16]<kadaan>:)
[16:55:22]<mstenta>i'll do this one manually
[16:55:25]<kadaan>I assume they were hosting locally.
[16:55:30]<mstenta>yup
[16:55:41]<mstenta>i definitely want to make an easy way to move from a local install to Farmier
[16:55:43]<kadaan>That's nice. The upsell.
[16:56:06]<mstenta>but - a straight SQL import isn't really feasible, because there are security implications to that
[16:56:14]<kadaan>In my world, I would export all as avro
[16:56:20]<mstenta>avro?
[16:56:51]<kadaan>It is a rich, schematized data format, like thrift, protocol buffers, etc.
[16:57:00]<kadaan>json compatible.
[16:57:01]<mstenta>huh never heard of it
[16:57:18]<kadaan>http://avro.apache.org/docs/current/
[16:57:48]<kadaan>Pretty common in big data.
[16:58:42]<kadaan>But I could imagine just exporting a ZIP with all the tables in it.
[16:58:53]<kadaan>And allowing the ZIP to be imported into Farmier.
[17:00:30]<mstenta>oh cool - under that Apache umbrella?
[17:00:40]<kadaan>Yup
[17:00:47]<mstenta>how do you export from SQL to avro?
[17:01:21]<mstenta>there are some other difficulties with importing SQL directly into farmier...
[17:01:25]<kadaan>I don't know if ther are PHP bindings though.
[17:01:36]<mstenta>if any customizations were made locally, they might not match up with the "stock" farmOS that Farmier hosts
[17:01:42]<kadaan>True.
[17:02:04]<mstenta>so i think the easiest option is to just build the proper import/export features in farmOS itself
[17:02:15]<kadaan>I don't know of a built-in way to export avro from sql.
[17:02:29]<kadaan>But json wold be fine.
[17:02:45]<mstenta>theoretically, we only really need a JSON importer... because you can already get JSON of all your farm entities via the restws module
[17:02:50]<kadaan>And the export could capture the relationshitpty easilty that way.
[17:03:08]<kadaan>In 8.x there is the json importer, right?
[17:05:28]<mstenta>yea exactly
[17:05:31]<mstenta>there might be
[17:05:41]<mstenta>so generally, in Drupal 7, Features is the best importer option
[17:05:45]<mstenta>sorry... not Features
[17:05:46]<mstenta>Feeds
[17:05:49]<mstenta>(tired) :-)
[17:06:20]<mstenta>it might be better for our purposes to just write a custom importer though
[17:06:25]<mstenta>specific to farmOS entity types
[17:06:50]<kadaan>Yeah. I had looked at feeds.
[17:07:05]<kadaan>I was hoping to get CSV export and import.
[17:07:25]<kadaan>JSON would be really good too.
[17:08:07]<kadaan>It would be really nice if there was some way that modules would end up getting this stuff for "free".
[17:08:26]<mstenta>hmm so you should be able to just do: http://[fqdn]/farm_asset.json
[17:08:31]<mstenta>and /log.json
[17:08:34]<mstenta>to get json of all entities
[17:08:47]<mstenta>but it seems that isn't working... i'm getting an access denied
[17:08:51]<mstenta>hmm i'll need to debug that
[17:08:52]<mstenta>brb
[17:08:56]<kadaan>k
[17:09:10]<kadaan>That would be another really useful piece of info.
[17:09:25]<kadaan>What dev tools do you use, how are you debugging, etc.
[17:27:21]<mstenta>yea definitely
[17:27:25]<mstenta>i use PHPStorm
[17:27:31]<mstenta>and XDebug
[17:27:35]<mstenta>and the Devel module
[17:32:32]<kadaan>I'll try the eap for phpstorm.
[17:33:25]<kadaan>Is XDebug something I have to install on the server?
[17:33:52]<kadaan>Guess I can figure it out here: https://www.jetbrains.com/help/phpstorm/2016.2/configuring-xdebug.html
[17:34:30]<kadaan>My teen daughter's homecoming dance has been changed to tomorrow at 3pm - 6pm... Lame...
[17:34:56]<mstenta>yea xdebug goes on the server
[17:35:08]<mstenta>wow - teenagers
[17:35:16]<mstenta>i've got that to look forward to
[17:35:41]<kadaan>Yup
[17:35:46]<kadaan>We have horrible weather right now.
[17:36:12]<kadaan>And so they rescheduled from tomorrow night to tomorrow afternoon.
[17:36:17]<kadaan>Kinda lame for a dance.
[17:36:49]<kadaan>I'll read this too if it is applicable: https://confluence.jetbrains.com/display/PhpStorm/Drupal+Development+usi...
[17:37:13]<mstenta>yea that is lame
[17:37:24]<mstenta>yea probably helpful
[17:37:36]<mstenta>there are some Drupal plugins for PHPStorm, but i've actually never used them
[17:37:46]<mstenta>when i started Drupal dev, I was just using a text editor
[17:37:50]<mstenta>so i got used to it there
[17:37:56]<mstenta>and then started using PHPStorm
[17:40:58]<mstenta>theres a really nifty thing called Coder http://drupal.org/project/coder
[17:41:34]<mstenta>it used to be a module, but now it is a php codesniffer plugin
[17:41:53]<mstenta>it basically scans through the PHP code and identifies places where coding standards need to be fixed
[17:42:13]<mstenta>that should go in the doc we make too
[17:42:26]<mstenta>so if you're interested, a really easy way to start making some contributions is in the documentation
[17:42:40]<mstenta>farmOS.org is all created using a thing called Mkdocs
[17:42:49]<mstenta>it essentially transforms Markdown files into a static site
[17:43:16]<mstenta>and it's hosted on github pages
[17:43:49]<mstenta>so all you do is run "mkdocs gh-deploy" and it automatically compiles them into HTML and CSS, and pushed them to a "gh-pages" branch in the repo, which Github Pages uses to serve the site from
[17:44:34]<mstenta>maybe i'll start a quick coding standards doc, and you can add to it as we figure out things that should be in there
[17:54:14]* kadaan has quit (Quit: My MacBook has gone to sleep. ZZZzzz…)
[18:51:56]* Kadaan has joined #farmos
[19:04:43]* kadaan_ has joined #farmos
[19:22:01]<kadaan_>I've used Mkdocs before
[19:22:16]<kadaan_>That sounds good.
[19:22:58]<kadaan_>We could setup code sniffer in phpstorm too: https://www.jetbrains.com/help/phpstorm/2016.2/using-php-code-sniffer-to...
[19:24:35]<mstenta>kadaan_: yea exactly! you can use it directly in phpstorm!
[19:24:44]<mstenta>and it will point out each line that you need to review
[19:24:51]<mstenta>double click and it brings you to it
[19:24:53]<mstenta>so convenient
[19:25:00]<kadaan_>Nice. If we get the right rules in there, that will really help.
[19:25:27]<mstenta>well yea... with http://drupal.org/project/coder, all the Drupal coding standards are there
[19:25:31]<mstenta>and that's all we really need
[19:25:48]<mstenta>outside of that, i think the only stuff we should define are process oriented
[19:26:24]<mstenta>for example: the other day i said that i always defer to Features to write code for me whenever possible
[19:26:39]<mstenta>and avoid making manual changes to that Features-exported code unless absolutely necessary
[19:26:47]<mstenta>that ensures a level of standardization
[19:26:54]<mstenta>that's one example
[19:27:06]<mstenta>in general i try to write as little code as possible
[19:27:12]<mstenta>the less custom stuff we have, the less we have to maintain
[19:27:51]<mstenta>stick with the best practices as much as possible, so that everything is easier to read, as long as you are coming at it from the standard practices
[19:28:03]<mstenta>and comment everything! every line of custom code!
[19:28:19]<mstenta>even if it's "obvious" what it does... i want to know WHY in a lot of cases
[19:28:26]<mstenta>the intention is a lot more important than the outcome
[19:28:49]<mstenta>maybe a lot of this is obvious, and the way you work, so pardon if it's redundant stuff
[19:29:11]<mstenta>i think it will be important to summarize a lot of these as official rules for farmOS contributions
[19:29:42]<mstenta>so that everyone has a place to start, and we have something to point to
[19:31:15]<kadaan_>Those seem like really good guidelines.
[19:32:22]<kadaan_>That said, I would love to figure out how to bake features into the core of farmOS, so that module developers don't have to produce a ton of code to get exports, imports, time tracking, etc.
[19:33:06]<kadaan_>If we were in 8.x, allowing module developers to configure their modules with yml and allow the specification of a lot of this would be really powerful.
[19:41:06]<mstenta>yea, Drupal 8 will be a whole new way of doing a lot of things
[19:41:20]<mstenta>that's also why i'd like to make sure we don't rush into it TOO quickly
[19:41:27]<mstenta>although I do want to get there asap
[19:41:28]<mstenta>haha
[19:41:40]<mstenta>but i need to learn some things myself too
[19:41:50]<mstenta>i've only just started playing around with it
[19:42:34]<mstenta>and yea - i sort of see farmOS as a very thin connective tissue holding a bunch of other non-farmOS pieces together
[19:42:41]<mstenta>the thinner the layer that is farmOS, the better...
[19:42:53]<mstenta>in other words, use existing contrib modules wherever possible
[19:43:00]<mstenta>the less we are maintaining ourselves, the better
[19:43:21]<mstenta>this is how the Drupal ecosystem works for the most part
[19:43:32]<mstenta>lots of generalized modules that serve as building blocks
[19:43:44]<mstenta>and farmOS is just a specific stacking of those blocks
[19:43:56]<mstenta>plus a FEW custom blocks here and there... but that's what we should try to minimize
[19:44:08]<mstenta>easier said than done, of course, but i think it's a good rule of thumb
[19:45:05]<mstenta>so remind me... did you say you do web development as your main job? aside from farming?
[19:45:43]<mstenta>what languages/ecosystems do you normally work in? you said you're new to php, right? (or am i mixing up conversations with someone else? sorry if so...)