Progressive Web Apps

November 29th, 2016 — 3:35pm

I recently spent some time researching “Progessive Web Apps”, or PWAs.  They are a relatively new way to make mobile apps which utilize the web browser, rather than requiring full installation via an app store.  Google seems to be driving this particulare movement.  Here are some links I used in my research:

Your First Progressive Web App – how to build a simple, functional app, with a demo included.

Debugging Service Workers – after you get into things, this link comes in handy

Web App Install Banners – this is how you get someone to install your “app” once it’s coded and ready.

Sampling of PWA tools

I’ll update this post as I find more resources, and publish a few PWA’s myself.  I think this is the future for many apps – easier to update and distribute and lower storage requirements on the device.

I was able to get a fairly simple web app set up here: Listomizer.  You can enter in a list of items, then have the app make a random choice, alphabetize them, or randomly sort them.  When you load this, your phone should ask you if you want to add a button to your home screen.  Then it looks like an app when you open it.

Comments Off on Progressive Web Apps | mobile, Programming

Perl – days ago subroutine

November 29th, 2016 — 8:27am

Here’s a small subroutine, written in Perl, which takes a date, and returns the number of days since this date:

#Pass date as mm/dd/yyyy hh:mm:ss and convert it to a # of days ago
sub days_ago {
 use Time::Local;
 my ($t) = @_;
 my ($date,$time) = split(/ /,$t);
 my ($mon,$day,$year) = split(/\//,$date);
 my ($hour,$min,$sec) = split(/:/,$time);
 my $last = timelocal($sec,$min,$hour,$day,$mon-1,$year);
 my $today = time();
 my $since = sprintf("%d",($today-$last)/(60*60*24));
 #print "<!--Days ago: $since - $sec,$min,$hour,$day,$mon,$year -->\n";
 return($since);
}

Example:

print &days_ago("10/01/2016 08:00:00");

Comments Off on Perl – days ago subroutine | Programming

Using Certain

November 11th, 2015 — 4:45pm

I have been working quite intensely with the event registration platform offered by certain.com.  Here I’ll offer a few insights about the experience.

First, the platform is very robust and stable.  It allows an event manager to control all aspects of online registration for an event, be it a course, expo, or full blown conference.  I am working mostly with the event / form building tools, which is powerful enough to create rather complex logic in the form flow.  Most screens and templates are customizable, and what can’t be done directly in the platform, can often be done by inserting some javascript or css code.  There is also an API which is very useful for extracting data to another platform.

There is also a robust report generation system, which allows for logic of its own, as well as “Mass actions” you can perform on many records at once.

The main drawbacks here are endemic to hosted platforms – since the code is not under your control, you need to live within the limits of what the programmers have given you.  Certain does release new updates regularly, and does take suggestions on new product features.

There’s not much of a user community, but the support and help documents are fairly good.

As a programmer, I’m noticing a trend here.  For a long time, the knock on “pre-packaged” software / platforms was just what I mentioned above.  You are limited to what is offered by the programmers.  However, as these platforms get more robust, the amount of customization allowed grows quickly.  So the need for custom programming is diminishing for more businesses out there.  I’ve seen this in other areas, such as ecommerce platforms, CRM’s, etc.

However, people with programming / logic skills still are usually required to really make use of the advanced features offered by these platforms.  There is essentially another “language”, ie. the language of “Certain”, or “zoho”, or “shopify”, etc. which takes a reasonably technical person to really get humming.

Comments Off on Using Certain | Web Tools

Thoughts on WooCommerce

June 10th, 2015 — 4:30pm

I recently had a chance to install and test WooCommerce for WordPress.  This is a very robust ecommerce shopping cart that integrates right into WordPress, which many sites use for their CMS.

While the plugin works pretty well, there are a few things to watch out for:

  • WooCommerce is “free”, but you would likely require some plugins – for example most of the shipping and credit card plugins cost money.  So by the time you are done, your “free” solution might cost $100-$200 in plugins.  This is still a reasonable bargain, but just be aware up front.
  • Some themes are WooCommerce compatible, but many are not.  Even so, integration is not too hard, just expect to spend some time / money getting the look of the shopping area customized.

Overall, though, I’m impressed with this plugin.  It’s a nice way to add purchasing functionality to your wordpress-run website.

Comments Off on Thoughts on WooCommerce | Wordpress

Expression Engine Followup

March 3rd, 2015 — 9:44am

Over the last few months, I’ve been working on a rather large project in Expression Engine.  This is a reflection on some of the lessons learned from that experience.

First of all, Expression Engine is meant to be a full fledged content management system and platform for custom functionality.  It allows creation of custom fields, and robust templating on the front end.

As with many CMS’s, there’s a steep learning curve for the programmers.  This included figuring out the best way to architect the use of templates, snippets, plugins, extensions, etc.  in a way that makes sense.  Figuring this out while learning EE was very difficult.  The parse order for templates was maddening to learn, along with all the nuances of the built in tags.  Due to the dynamic nature of the site, relatively little caching was used, so each page is pretty heavy with mysql queries.  Because EE has complex permissions, each template generates many database queries to figure out the final rendering.

In addition, most EE settings, including templates are stored by default in the database.  So it’s hard to track changes to the site using traditional methods (git or another version control system).  It also meant most editing was done in the Web GUI, rather than my preferred editor.

Another drawback is that database tables are all intermixed – so as a “channel” is added with custom fields, the channel data and fields are all mixed in with other channel data.  So, for example, you can’t pick out the “news” table of the database if some data needs to be imported or restored.

Expression Engine has a lot of plugins / extensions, but many are paid.  In our case, we spent maybe $100 on plugins to get the functionality we needed, but also programmed some custom add-ons that we needed.  EE also has a fee for the license if used on a commercial site, so that was a fee as well.

Overall, I see that EE can be a pretty useful CMS.  For this particular project, the functionality was perhaps a bit too dynamic and heavy for EE, though in the end we did make it work.  It did save us a lot of time by not having to build the admin backend.  For most sites, I expect EE would work fairly well, and I plan to use it again when appropriate.

Comments Off on Expression Engine Followup | Programming

Back to top