[u-u] Electronic signage...

[Colin McGregor]

On Thu, Jul 14, 2016 at 10:14 PM, Eric Siegerman <pub08-uu at davor.org> wrote:
> I'm on the HTML side.  It pisses me off that web apps have taken
> over the world -- that's a rather icky platform to write for --
> but for what you're talking about, it seems a very good choice.
>
> One of the problems has been browser-compatibility issues.  I
> have the impression (*not* backed up by experience) that things
> have improved on that score; but even if they haven't, it's a
> non-issue for your application, since you get to specify the
> browser and version.

Yes, my sandbox, I run it :-) .

> On Thu, 14 Jul 2016 11:55:12 -0400, Colin McGregor
> <colin.mc151 at gmail.com> wrote:
>> Finding someone to carry this
>> project forward from within the volunteer talent pool of a sailing
>> club will then become the issue.  Which will be easier to find,
>> someone who knows HTML or Python?
>
> False dichotomy :-)  I'd suggest using HTML *and* Python.  Or
> maybe Ruby or PHP.

True...

On Friday I placed an order for a barometric pressure sensor, a
BMP180, in part because there is already a Raspberry Pi Python library
that will let me read the current pressure (details here :
https://www.adafruit.com/products/1603 and
https://github.com/adafruit/Adafruit_Python_BMP ). The funny thing, as
I mentioned at the last UU meeting, I (and most sailors) don't really
care what the current atmospheric pressure is. High pressure is
associated with good weather, low pressure is associated with bad
weather. So, for predictive purposes I want to know what the trends
are, pressure increasing means better weather is coming, pressure
falling means worse weather is coming and pressure staying the same
indicates more of the same weather. This means taking a series of
readings over a period of time and determining a trend (if present).
So, got the software in Python to take one reading, next will be more
Python to calculate trends...

> Reasons:
>  - Anything interpreted and memory-managed is going to be easier
>    for you to write, and for your successors to maintain, than C
>    is
>
>  - Down the road, I believe you'll be far more likely to find
>    someone who knows those languages than a C programmer.  (And
>    even if they know a different one of the three than you used,
>    the learning curve will be easier for them than going from any
>    of them to C.)
>
> I have a personal preference among them, but reasonable people
> can differ.  ('Nuff said about that; if I go into detail, it'll
> be flamewar bait....)
>
> (Perl would also be a good technical fit, but it's pretty
> trailing-edge at this point -- popularity is low and getting
> lower -- so it's not a great choice from a future-handover point
> of view.)
>
>
> In terms of the overall architecture, if I were building this
> thing, I'd write a bunch of little Python (or whatever) scripts
> for data collection/translation/formatting (as opposed to one big
> hairy program).

Yes, makes sense to do this as one script per sensor, this way one can
upgrade/replace sensor X and not have to worry that sensor Y will
break.

> Run them from cron -- not sure who said that, but yeah!  (Unless
> in a given instance, it makes more sense to make a collector a
> single long-lived process.  Not sure why that might be, but there
> might be a reason.)

The pressure program may make sense to run as a long term process,
take a reading once per minute and calculate trends over the last 6?
hours. It will be an interesting learning experience with real world
sensors, things like analysis of real world data and trying to figure
out when/how to detect/throw away bad data (like what happens when
someone cleaning the hall brings a vacuum cleaner by the barometric
pressure sensor)... Computer should know to discard some readings
(like when they are below any reading ever recorded on Earth :-) ).

> As for turning the collected data into a web page:
>   - you could do the AJAX thing, using Javascript to slurp in the
>     saved data
>
>   - or (and here's where my own old-school biases start to show
>     :-)), a low-tech approach would be to have another cron job
>     that just spits out a static HTML page, which the browser
>     then periodically refreshes from
>
>   - or use Dan(?)'s IFRAME idea.  Actually, I think I like this
>     the best.  Simple, clean, and changing the layout doesn't
>     involve code, only editing the master HTML file.  Plus, it'll
>     probably be the easiest way to deal with the video feed from
>     the camera

Yes, I've fallen in love with this idea. I've set-up a table and then
dropped in IFRAME commands linking to supporting HTML files that do
one element of the display (ie: one that does "Upcoming Events",
another the "Current Time", another the "Weather Forecast", etc.).
This means I can fix/improve one element without breaking others. For
example, my Upcoming Events HTML depends on the HTML <marquee> command
which for several reasons is considered a problem. So, until I can get
to doing a better Upcoming Events I have something that works, and if
it does break it will not mess up the rest of the screen. Also this
makes running more than one Javascript program at the same time
painless.

> The choice you make here will inform the decision as to whether
> the data-collector scripts should write their output as HTML
> fragments or simply data (JSON, XML, CSV, YAML, or whatever).
>
> Sounds like a fun little project.

It is.

Colin.

>   - Eric
> _______________________________________________
> u-u mailing list
> u-u at unixunanimous.org
> https://unixunanimous.org/mailman/listinfo/u-u