The rigged imager

   Recently having purchased smartphone X from store.  M__ attempted numerous self portrait shots.  Numerous more than he could say, and all images seemed to provide a distinction relative to the image that were commonly viewed in front of the mirror.  Why is it always very similar?

Downcast and disheveled face, cheeks puffy and slightly discolored, M__ appeared tired and worn, he appeared haggard.  Obviously outdoor lighting seemed to provide greater improvement for his appearance.  Camera's don't lie, do they? 

The truth of the matter for a ccd imager an image is processed and calibrated in some representational way for all the incoming light, the imager is calibrated in terms of human visual perception.  It isn't accurate in some ways as it is calibrated in an average way to visual perception.  Some see colors differently, and some perceive the vibrance of some colors distinctly relative others...and some even see colors in sounds, and smells, as connected to other senses, that is, given a neurological crossing of wires mixing sensory states.

The truth of the matter is that even a compiled image from a smartphone or camera is likely to be processed whether a user likes it or not.  That is reprocessing an image potentially from a RAW digital format into other media formats which approximate original raw binary data through a number of mathematical transformations, and not permitting all the calibrations that supposedly are meant in emulating a perception like human optics.  The image is filtered, and so it is assumed that the image in a given instantaneous moment that is still image is gathered is representational of its subject matter, save the apparent snow that has gathered in the image...could this be the interference, for instance, of something like cosmic rays having perpetuated when not enough visible light should exist for the duration that a shutter had gathered whatever photons that could be had? 

The light were more sickly yellow than he would have recalled, at least, if it were his eyes, neither had he perceived so much white noise (snow) in the image of a room that appeared darker than he recalled, having shown him in unflattering ways. 

A clinical white wash of light shown overhead as M__ gazed into a mirror.  Yes, perhaps, I can see more a blemish here and there.  Signs of aging that he'd convince himself must have existed only having overlooked this or that, the camera hadn't perpetual misheard him, but looked upon the details in some objective way it would seem...don't we have a tendency to think of ourselves in continuity to a greater depth than extends beyond surface?

M__ noticed over the course of months and years that his face changed, as one might expect with years in aging.  Changing as in some mutability of self, that one would expect, irrespective of the continuity of the self "I" that M__ knew.  I being there, M__ thought. 
A slight shift in angle, a distinct head posture, a facial expression that essentially conveys something beyond a transient misappropriation of body languages that coincided for all purposes to bad timing, but just so happened to be the case more often than not.  So much less thought into that resident expression that betrays all other expressions. 

There is no grudge in that discrimination given by algorithms.  It is posited as certainly as facial recognition employs the framing of a face and has a spatial appropriation created so instantaneous that the tag box need be employed perpetually in the frame() method (until instructed otherwise).  That is where the eyes, nose, and mouth exists.  The curvature of that mouth alongside the topological models that would be instantaneously conceived following the smooth curvature of facial muscular structures.  A lifting of the cheeks, lifts the corners and creases  of the mouths...long since understood by those in art and medicine.  Turn that smile into a frown.  Cross one eye with another...a strange asymmetrical gait is more noticeable than one that is not.  Human minds by evolution discern such noticeable patterns right away, and in sensing discriminate one face from another.   Machine language manipulated all such data in a dizzying way.  Much more rapidly than any human artist could conceive, that is, in continuity of one thirtieth of a frame per second or 1/30 seconds a rendered frame with all necessary ingredients to convey what need be conveyed.

M__ wouldn't have better on a given day that he were apparently tired, wouldn't have felt better on a day that seemed haplessly the same as the day before. 

For the endless string of days, he were postured like a puppet in an endless choreography, all such social capital spent away, and where likely social credit should be less common place.  Restricting his travel was all part of the system, as in the litany and narrative, describing its own self continuity, to readers and onlookers so often far away. 

His mind traversed the image that would be his own self memory, self invention that surely was in his own domain as equally as it were removed.  Something that no one would see in a world where few did gaze so much at the faces of others really.

Recent Study on the Ride Share Gig Economy and Added Thoughts

Here is the study:

http://ceepr.mit.edu/files/papers/2018-005-Brief.pdf

Notable highlight:

"We perform a detailed analysis of Uber and Lyft ride-hailing driver economics by pairing results from a survey of over 1100 drivers with detailed vehicle cost information. Results show that per hour worked, median profit from driving is $3.37/hour before taxes, and 74% of drivers earn less than the minimum wage in their state. 30% of drivers are actually losing money once vehicle expenses are included. On a per-mile basis, median gross driver revenue is $0.59/mile but vehicle operating expenses reduce real driver profit to a median of $0.29/mile. For tax purposes the $0.54/mile standard mileage deduction in 2016 means that nearly half of drivers can declare a loss on their taxes. If drivers are fully able to capitalize on these losses for tax purposes, 73.5% of an estimated U.S. market $4.8B in annual ride-hailing driver profit is untaxed."

And this is the rub for an industry that maintains a substantial market.

Added thoughts:

Uber or Lyft having externalized transportation cost infrastructure to ride share drivers removes incentive in provisioning scarcity to ride share driver supply.  While on the other hand, potentially encouraging market growth for demand, as some consumer have related, the average time to service could be in some cases considerably lower relative to traditional cab services.   Market saturation of supply drivers likely leads more likely to shortened arrival times for supply customers while ensuring greater likelihood of ride share orders being fulfilled as opposed to cancelled.  Also having externalized transportation costs in such way, it has the advantage in cost leveraging the cost per ride to consumer while maintaining profit margins relative to traditional ride services.  This displacement, of course, is passed to drivers of the ride share service.

Here are additional factors that can make pay rates quite low:

• Cost per ride doesn't pay as much when minimum hourly pay rates are non existent.  
• The frequency of rides per hour are small alongside small mileage added to lengthier deployment times and mileage in providing a ride in the first place.  That is, unpaid travel distance meeting small paid travel distance.  
• Too much downtime travel distance.
• Too many drivers in queue for a given location (e.g., waiting at the airport with 96 others in queue), not enough demand.

Maximizing travel fares:

• Frequenting locations where clients may be utilizing transportation in specialized ways as opposed to a primary source of transportation.     
• Choosing locations where clients that use ride share as primary means more frequently may be more likely to use the service, in absence to public transportation offering, for shorter trips and especially in non specialized ways.  
• Events based ride shares could potentially have better pay outs since these are more likely to require highway miles and lengthier travel times.  
• Pickups with drop off at the airport especially where travel distance to and from are increased. 
• Reducing non paid travel time.
• Finding minimum distance routes to higher frequency ride share demand locations.
• Use multiple ride shares (if possible). 
• Reducing total per day travel miles while increasing the number of rides per day.  
• Offering ride share when the pay makes sense.  What is a base hour rate goal?  Getting paid to do other things when typical base hour rate during such time isn't in keeping.  
• Doing ride share in conjunction with other types of paid services (e.g., not Uber delivers but other types of specialty delivery services that pay decent).  Thus signing on to Uber to offset downtime loss of income when other delivery and/or transport services are slow as means to supplement primary income as opposed to primary means.   

Because Ride Share conceptualizes the market of drivers as intelligently driven by the supply of drivers and consumers more so, there is likely more managerial stress burden placed upon drivers to make critical economic decisions as to whether or not the market is viable as a means to income.  The gig economy is revolutionizing the ways that time is spent and the valuation for such.  Like the outset of the industrial revolution and all ramifications entailed by emerging technologies and sociological manifestation therein, it as likely that society is being transformed to think in different ways about the utilization of time and resources.  There is the power of potential exploitation and maybe in the future greater empowerment for individuals in maximizing their returns for time spent.  Proliferating diversification of gig related work is a likely reality for our economy.  Increasingly companies, corporations may be looking to pay independent contractors for task related work as opposed to lengthier paid downtime stays.  This inherently puts greater time management stress on individuals in such economy to maintain some paid work load when it is necessary, but also being intelligently cognizant in ways that were less commonplace in the past.  Knowledge and task based services as they become increasingly transient in terms of continued usage will likely mean less are as highly specialized in providing services and more likely having better adaptive management skills and/or utilizing adaptive management services that makes more likely effectiveness of individuals in being able to deliver profitably skills sets, services and products.  One should predict that our future economy will likely put greater premiums (not less) for task service related deliveries if it is ever to be sustainable.  Of course, externalizing lean efficiency is yet another thing... 

Thus a maxim:  Don't be afraid to express your worth for what you are doing and don't settle for less.

Icelandic Summer Landmannalaugar Solo Trekking and Camping Guide

   I want to make this post brief.  Mostly there's a lot of travel guides out that mention considerations to Icelandic weather, heed the advice, but I'll add something additional here.  Iceland is a Northerly country subject to more extreme weather conditions even in the summer.  It can be sunny and generally nice, even while it is cooler, and then it can be more extreme in terms of gales and stormy weather.

This past summer I managed to do the Landmannalaugar trek, but also encountered more severe gales.  The weather events were enough to have a warden shutting down the trails, and strongly suggesting camper's (with tents) to take up adequate shelter.  One particular camp was closed so that my starting day thru hike from the first destination point was instead differed to a third camp site.  That is going from the interior highlands south to the lowlands.  I decided (owing to getting ahead of an incoming storm) not to stay at a higher altitude alpine location and instead thru hike to the second location which was lower elevation, but even so were deferred to a third location.  That being said, extreme weather events can lead to camp closures if warden's make decisions that adequate shelter isn't afforded.  Also expect thru severe weather events that wardens may close the trails down (in our case a full day).  Quite likely though you wouldn't want to be out there anyways.  Just keep this in mind when factoring time schedules.

Fortunately the trek does provide a number of bus opportunities, but I would suggest taking note of schedule if you intend to use this.  Don't assume that huts (because they are advertised) are likely to be open.  First come, first serve?  Sort of, but not really.  During the height of tourist season, as I experienced, and especially during a severe weather event, the huts tend to be in high demand, but especially by paid tour groups, so unless you have exclusive reservation through a tour company, don't count on a hut being available, and make that even less likely if severe weather comes.  Going with paid touring companies affords more likely access to huts, and/or luxury treatments for trekking.
Wise to bring a three or four season tent.  I rode out severe storm with extremely high wind gales in a three season hiker's light weight tent which served well especially when sheltered in with a stone wall for weather reinforcement.

If it storms and severely so, you will likely deal with plenty of water (especially given all the river and stream crossings).  The deepest stream was nearer to the Thorsmark terminus which (at that time of the year...July) was waist high and generally a stronger current...I am six feet in height.  Highly recommend trekking poles for the crossing and/or managing to scout an adequate channel crossing site.  Keep pack belt un clipped so that your pack can be evacuated from your back in rapid fashion should you fall into the stream.  The water is glacial cold.  Wet shoes with decent traction and/or water sandals (same) can come in handy.  Gaiters are likely fine for most of the highlands, not so good where the streams in south are deeper...most stream crossing can do better with water wear for your feet.  Just change before and after crossing from dry to wet footwear and so forth.

I had witnessed a number on my trek through hiking to Thorsmark in a two or three day journey or busing out earlier because of weather conditions.  Most it appeared especially came into Thorsmark early (from our starting group) likely because of wet gear or the inability to keep gear sufficiently dry.  I, fortunately managed to keep gear dry through the duration of the severest weather, but found that on the tail end of the worst storm, my gear was saturated.   Thus I would suggest some added things for a tent.  One, it has a rain fly vestibule area where hiking boots and/or additional gear not stored in the tent can be kept in dry safe keeping, or that alternately you have a rain tarp situated so as to provide your tent additional dry space.  Secondly, compartmentalizing tent and sleeping bags or anything in tote from one another to ensure that water doesn't creep saturate internally other parts of your gear another thing to keep in mind.  Stowing an external rain tarp outside your pack can simplify this, or keeping the rain fly of your tent plastic bag stowed and segregated from other dry gear should help a lot.  Don't assume a rain cover for your pack is enough.

High humidity can more likely bring ruin to your down bag experience...consider synthetic bags.  Consider woolens and synthetic wear.  Bring and expect to use layers. 

Another small secret I'll share with you...I asked a warden, if my family home would see present weather conditions where I was at...she replied, 'That information most certainly will not be published outside Iceland!'  While I used free Wi Fi hotspots throughout Iceland.  I found none on the trek.  Something to be aware of if you intend to use wifi as a means of communication.  As to cellular service and using your existing phone abroad, check in advance.

Guides will tell you to expect much...don't assume that the weather reports that you see are what to expect before you go...its always sunny and nice, till you get there... who wants to lose revenue anyways?  :)

React and Redux

What is the difference?

One I hadn't wanted to attempt as thorough researcher to answer this question with technical ins and outs, but rather approach this with a simplest possible answer, at least a reduced answer that avoids all the technical ins and outs of differences here.

One while react does provide in its framework controller model and controller logic interfacing, by far, React provides a framework with the design aspect of encapsulating mvc structure in a component by component basis and View predominant in its focus.  While React can be designed functional in nature, it seems to me to lend itself to classical OOP design patterns.  It is, of course, also quite easy to learn and trending popular in terms of adoption and use.

Redux apps on the other hand may share some structural difference to MVC design patterns in the way of separating Controller and Model logic with the that of the view systems, as opposed to having a compact all in one strictly component integration.  That is, in housing model and controller logic to the component.  Redux logic separate Controller logic into, for instance, actions and states of the app, and making ease in generalizing the state and actions of the application across components and containers, which are components that merely handle the delegation of component actions and states.  It is also one of a functional design pattern that provides injection patterns into component and containers alike, so it also extends functional design in a positive way given flexibility and power in evolving state and action of the app.  The downside (if such is appropriate) is that Redux has a higher learning curve for adoption, at least in the pure sense of learning redux without middleware helpers.

Which to use?

If you were wanting to gain experience with Redux design and especially functional programming work, it seems Redux would be a good choice.

If you have complex state and action managements for you Web Apps design patterns, Redux may also be  another good choice, though as I've read for asynchronous management, you may need some added middle ware helper (Redux provides advice on this).

If you are new to creating Web Apps or want something that easy to dive into, React is great as a learning tool and creating a web app quickly.   React provides great versatility and state management is especially easy to understand and implement.  However, complex state management systems with two way bindings and especially implementing a generalized state management system could be also just as cumbersome work in React relative to Redux.  Thus I've seen, for instance, WebRTC web apps designed in Redux relative to being purely React, and there's likely no coincidence where app states and actions would need be shared across a number of components since an overarching controller system provides some clarity to the approach of binding data.  Redux, add goes beyond what Angular provides here especially where Angular component models increasingly resemble the simplicity of React's components which has been the trend apparently for any number of web app frameworks.
 While two way bindings, for instance, attend to the problem of two way state mutations, in React or Angular for that matter, on the other, hand I've found myself violating the mutability principle of functional programming design.  That is, instead of mutating the inputs, providing a return object that expresses a new state.  Redux, in this way, could be considered the preferable approach if and wherever app design patterns make use of two way bindings between child and parent components and is required.

If you know neither, perhaps, it may help to understand React first and then learn Redux.  Though when learning Redux provides for enough distinction to think of Redux app by way of Redux design through its native api documentation (React may not be helpful) alone.  Trying to understand Redux, through React documentation, in other words, can get in the way, in my opinion.

React is to Redux, however, arguably for what Python is to C++...which is something to keep in mind. 

Admin email notifications with firebase database write queries (JavaScript)

Prerequisites:

•  NodeJS with NPM installed.  
•  Google Firebase Account

    With your favorite web app framework you can configure your web app to auto generate emails based on site user feedback.

I've used ReactJS in this case for a generic contact us model form submission.  A quick tutorial on getting started with React JS and setting up this model can be found at:

https://www.codementor.io/yurio/all-you-need-is-react-firebase-4v7g9p4kf



   In this project I adapted recipes given for firebase user authenticated additions... from sites:

https://www.menubar.io/firebase-functions-sending-emails/

and

https://github.com/firebase/functions-samples/tree/master/quickstarts/email-users

Follow the quickstart tutorial in the functions-samples link.  Namely, in setting up your gmail account to send emails via node mailer.
Once say you have your react project or whatever project using firebase set up.  You'd need to go to that particular folder and initialize firebase functions...to do this actually will require potentially a couple of proceeding console commands at the root of your project directory:

npm install firebase-functions@latest firebase-admin@latest --save
npm install -g firebase-tools

then

firebase init functions

Go into the functions directory (via command prompt or console/terminal) and type:

npm install nodemailer --save

node package manager will initialize the project with the functions folder and install (provided your acceptance) the necessary node packages.  Note:  highly recommend that you double check your git ignore file and configure the ignore for the functions folder if you are using git.

An adapted code (from the above links), for instance, in sending email notifications looks like this:

const functions = require('firebase-functions');

const nodemailer = require('nodemailer');
// Configure the email transport using the default SMTP transport and a GMail account.
// For Gmail, enable these:
// 1. https://www.google.com/settings/security/lesssecureapps
// 2. https://accounts.google.com/DisplayUnlockCaptcha
// For other types of transports such as Sendgrid see https://nodemailer.com/transports/
// TODO: Configure the `gmail.email` and `gmail.password` Google Cloud environment variables.
const gmailEmail = `****@gmail.com`;
const gmailPassword = `*****`;
const mailTransport = nodemailer.createTransport({
  service: 'gmail',
  auth: {
    user: gmailEmail,
    pass: gmailPassword
  }
});

// // Create and Deploy Your First Cloud Functions
// // https://firebase.google.com/docs/functions/write-firebase-functions
//
// exports.helloWorld = functions.https.onRequest((request, response) => {
//  response.send("Hello from Firebase!");
// });
const APP_NAME = 'Cloud Storage for Firebase quickstart';
exports.sendFEmail = functions.database.ref('messages/{uid}').onWrite(event => {

    // only trigger for new users [event.data.previous.exists()]
    // do not trigger on delete [!event.data.exists()]
    if (!event.data.exists() || event.data.previous.exists()) {
      return
    }
  
    var user = event.data.val()
    console.log(user);
    var {email} = user

      const mailOptions = {
        from: `${APP_NAME} `,
        to: `****@gmail.com`
      };
    
      // The user subscribed to the newsletter.
      mailOptions.subject = `**** Contact Notice!`;
      mailOptions.text = `${user.name} sent a message!. Here is the message:  ${user.message}.  This is the sender's email address:  ${user.email}`;
      return mailTransport.sendMail(mailOptions).then(() => {
        console.log('message sent!');
      });
    })

You'll put this code say in an index.js file in the functions directory...just replace the existing default code set.

Now you can easily deploy this up to firebase...
In your project's root directory in console just type:

firebase deploy --only functions

This pushes the function up as firebase function...what does this code do?

Reading the line  "functions.database.ref('messages/{uid}').onWrite(event..."

This is an event handler set on the database called when ever a write event occurs on the database 'messages' database key.  When a post request is created on the firebase database writing a new database entry, the event handler function is called.

The event handler in this case, if you are doing further reading, refers the database entry set as 'user'.
The object 'mailOptions' is passed in turn to the mailTransport inside the method sendMail...noting for nodemailer this is parameter nature of sending mail.

Suggested reading for further firebase api documentation as related to real time database event handling:
https://firebase.google.com/docs/functions/database-events

Future Speculations for future devs

    Toss out the notion of "experience" or being "experienced"...this will be a malinger to outmoded industry practice.  It isn't what we know anymore that matters.  Your mastery is less regarded by specialty to anyone thing, but given to new things.  New Frameworks will emerge as old one's die, though an ecology settles into more common practices.  There is too much to learn with little time for a given dev industry to claim expert.  Pay attention to your communication or lack thereof...the future is about hand holding given so much flux!  No one is interested in stable industry practice...they are interested in disruptive practices!  AI handles the rest!  The future is dizzying with new technologies and scary at that!  You will have switched to one framework after another in a given days pace! And having exposed your self to a new language all the same on a daily basis!

The Self Paradigm

   The essence of being is always accounted for in ways given constraints.   Mythology of the self.  Apparently given rise of a new dangerous youth...that we are likely fragmented in a way by technology that imperils our connectivity to others around us, yet seems conspicuously born of a similar fantasy that has alongside plagued civilization since its inception.  Neither is it so easy to say that our minds haven't changed.  The self paradigm is given by the paradox of something that has long been unsettled, always mutable and shifting as easily.  What is healthy of our behavioral patterns in such question, one might ask?  That we persist in asking the same questions of ourselves while insular indoctrination abounds beyond the conspiracy of tethering mobile devices? 
More than the smartphone alone is responsible in rewiring the self as we have perceived it...what do we admit of the mythology of the self paradigm?

We start at the premise of my invented country and we start at the premise of my invented self.