emGee Software Solutions Custom Database Applications

Share this

Web Technologies

Array Explorer and Object Explorer

CSS-Tricks - Wed, 01/03/2018 - 11:38

Sarah made these incredibly handy interactive code reference... thingers.

The idea is perfect. I'm in this position regularly. I know what I have (i.e. an array or an object). I know what I want to do with it (i.e. get an array of all the keys in my object). But I forget the actual method name. These thingers guide you to the right method by letting you tell it what you got and what you wanna do.

Array Explorer

See the Pen Array Explorer by Sarah Drasner (@sdras) on CodePen.

Object Explorer

See the Pen Object Explorer by Sarah Drasner (@sdras) on CodePen.

Array Explorer and Object Explorer is a post from CSS-Tricks

Categories: Web Technologies

Benchmarking ProxySQL 1.4.4

Planet MySQL - Wed, 01/03/2018 - 09:06
Comparing ProxySQL 1.4.3 vs. 1.4.4

ProxySQL 1.4.4 has recently been released (GA on Dec 20, 2017) which naturally leads to the question “What performance gains are to be expected when moving to the new version?”. In this article we compare performance between 1.4.3 and 1.4.4 in a CPU bound workload. The instances are configured with the default settings for the initial benchmark and then again after tuning one specific variable, mysql-max_stmts_per_connection, which can lead to substantial performance gains.

Lets first discuss what the ProxySQL variable mysql-max_stmts_per_connection affects and how it is evaluated. ProxySQL maintains a counter for each backend connection which increments each time a statement is prepared on that connection. Just before the connection is returned to the pool, this counter is evaluated against mysql-max_stmts_per_connection, and if the threshold is exceeded then the connection is closed (behaviour up to version 1.4.3) else the connection is reset (behaviour starting version 1.4.4 in order to improve the efficiency of connection handling as pointed out in Percona’s blog post regarding: XtraDB Cluster best practices for AWS).

Note: The mysql-max_stmts_per_connection variable is configured to 20 by default and can be tuned up however keep in mind that when increasing mysql-max_stmts_per_connection you may need to also increase the value of the MySQL variable max_prepared_stmt_count which has a maximum limit of 1048576.

In the graphs below performance is compared between ProxySQL version 1.4.3 and 1.4.4 using default values and two benchmarks for each (one with mysql-max_stmts_per_connection set to 20 [default] and another with the variable set to 100). A Sysbench benchmark was executed for 300 seconds with 64x threads performing a mixture of point and range selects on 10x tables consisting of 40,000,000 rows each running on a 3x node Percona XtraDB Cluster each running on 40x cores and 1 Gbps NICs.

The key averages for each benchmark are as follows:

Metric 1.4.3
(default) 1.4.4
(default) 1.4.3
(mspc 100) 1.4.4
(mspc 100) QPS (average) 126179.53 141689.68 155537.27 163209.93 Latency (average) 14.67 13.10 11.93 11.37 Latency (95th percentile) 18.28 16.41 15.55 14.73
  • It is interesting to note that ProxySQL 1.4.4 is 13% faster out of the box with the default settings compared to ProxySQL 1.4.3.
  • It is also quite interesting to see that when mysql-max_stmts_per_connection is tuned to 100, and for this specific workload, ProxySQL 1.4.3 in itself could perform 24% faster!
  • With ProxySQL 1.4.4 we can see that when mysql-max_stmts_per_connection is tuned to 100 performance is 15% faster, however this is still 5% faster than ProxySQL 1.4.3 when tuned as the code is more efficient in the newer release.
  • A similar trend can be seen in terms of latency between the various versions of ProxySQL and the tuning of the mysql-max_stmts_per_connection variable.
  • Once again ProxySQL 1.4.4 exhibits the lowest amount of latency (especially when mysql-max_stmts_per_connection is tuned higher than the default value).
  • Naturally the effects of the mysql-max_stmts_per_connection variable largely depend on your workload and a synthetic read only sysbench workload serves more for comparative purposes.

Based on the above benchmarks it is fair to say that ProxySQL 1.4.4 has more consistent and efficient performance with regards to 1.4.3 resulting in at least a 13% improvement in average QPS and a 15% improvement in terms of average Latency out of the box.

### For reference, the command used to benchmark was: sysbench --threads=64 /usr/share/sysbench/oltp_read_only.lua --tables=10 --table-size=40000000 --report-interval=5 --rand-type=pareto --forced-shutdown=1 --time=300 --events=0 --percentile=95 --mysql-user=sbtest --mysql-password=$pw --mysql-db=sbtest10t40M --mysql-storage-engine=INNODB --mysql-host=127.0.0.1 --mysql-port=6033 --point-selects=25 --range_size=5 --skip_trx=on run

Authored by: Nick Vyzas

Categories: Web Technologies

Improving the Accessibility of 24 ways

CSS-Tricks - Wed, 01/03/2018 - 06:41

I’ve been thinking recently about the nature of my work and which aspects of it I enjoy the most. In a role that will often straddle the realms of design and development, whether editing copy, evaluating the design of an interface or refactoring code, I've come to realize that my interests lie in the act of review and refinement.

My work on 24 ways is a case in point. Since Drew McLellan asked me to redesign the site in 2013, I’ve stayed on as part of the team, helping to review, edit and format articles. But I’ve also been able to fulfil the desire I expressed upon launching the redesign:

I'm a big believer in iteration and not treating a website as ever being finished. I hope what’s been released this year can act as a foundation, and that the design will evolve in the years to come.

In the intervening years, as tools have improved and best practices have matured, I've tweaked the design and refactored the code, and developed a component library in the process.

The 24 ways home page A Focus on Accessibility

This year I've been listening to people like Laura Kalbag talk about accessibility in terms of universal design, and followed blogs like Heydon Pickering’s Inclusive Components, which covers how to design and implement common interaction patterns with an inclusive mindset. All of a sudden, the thorny subject of accessibility has felt more approachable and less dogmatic.

With all this knowledge digested, I was keen to see how 24 ways would fare when put under the microscope. In this article, I will cover five areas where I was able to make improvements:

  • Page structure
  • Labelling of elements
  • Keyboard navigation
  • Aural experience
  • General usability

Before I start, a note of thanks. After making an initial set of changes, I asked my friend and accessibility expert Francis Storr to review my work. He uncovered a number of additional issues, partly the result of his experience in this area, but also from having tested the site with a range of different assistive tools.

Rethinking Page Structure

The original design had adopted a mobile-first approach. The navigation was deprioritized and placed towards the bottom of the page. To ensure that it could be accessed from the top of the page in non-JavaScript scenarios, I added a skip to navigation link. If JavaScript was available, this link was co-opted to reveal a navigation drawer, which would slide in from the top or right, depending on the width of the viewport. This resulted in the following page structure:

<header class="c-banner">…</header> <a class="c-menu" href="#menu">Jump to menu</a> <main class="c-main">…</main> <nav class="c-navigation" id="menu"> <div class="c-traverse-nav">…</div> <div class="c-navigation__drawer"/>…</div> </nav> <footer class="c-contentinfo">…</footer>

In retrospect, this was problematic in a number of ways:

  • The menu button (.c-menu) was not adjacent to the element it controlled (c-navigation-drawer). Moving focus around the page like this can be confusing, especially if it’s not managed properly.
  • All navigation on the site was grouped together, even though each set of links served a different purpose.
  • The drawer behaviour relied on having a link behave like a button. However, the first rule of ARIA states:

    If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so

    Last year, I updated the JavaScript so that this link would be replaced by a button, yet this complexity was a hint that my original solution was sub-optimal.

Here's the structure I arrived at today:

<header class="c-banner"> … <a class="c-banner__skip" href="#main">Skip to content</a> </header> <div class="c-menu"> <button class="c-menu__button">…</button> <div class="c-menu__drawer">…</div> </div> <main class="c-main" id="main">…</main> <nav class="c-traverse-nav">…</nav> <footer class="c-contentinfo">…</footer>

Moving the navigation towards the top of the page meant the button and drawer were now adjacent to each other. The menu button is no longer two-faced; it is and always will be a button.

A downside to this approach is that the navigation can be heard every time you visit a new page. Again, we can use a skip link, but this time one that points to the content block (#main). Rather than hide this focusable element from certain users, it becomes visible on focus.

This structure may be less ideologically pure, but it’s far more pragmatic. This became a recurring theme. Indeed, having given up any hope of the HTML5 outline algorithm ever being supported by browsers, I stopped using h1 for section headings and followed the recommendation that heading ranks should be used to convey document structure instead.

Improving Keyboard Navigation

As the most interactive component on the site, the menu was the unsurprising focus of my review. The design dictates that the navigation drawer should behave like a dialog, an interface pattern that brings with it a number of assumptions. These are described in detail in eBay's MIND pattern, but essentially a dialog draws focus away from other elements on the page and is modal; only elements within it can be operated while it is open.

I had previously cobbled together various bits of JavaScript to handle focusing (cobbling which at various points produced the odd bug such as failing to draw focus to the first element in the dialog), but had neglected to indicate the menu’s role. Having fixed these issues (adding role='dialog' when the menu is open), Francis pointed out that screen readers could still access links outside the dialog when it was open. In macOS VoiceOver for example, pressing CTRL + OPT + CMD + L to navigate links within the menu, would in fact announce every link on the page.

The solution was to mark everything outside the dialog as "inert". Rob Dodson describes this in more detail in his video Accessible Modal Dialogs. Implementing this can be a little bit fiddly, but a proposal to introduce an inert attribute would make this easier to manage. In the meantime, the proposal provides a polyfill so you can use this feature today.

I’ve found that by thinking about an interface in terms of common interaction patterns, and how they should operate in order to be widely understood, has helped me avoid complexity, and write more robust code. In fact, stepping into the world of accessibility has uncovered a wealth of useful resources, with well-written JavaScript examples a plenty. Given my difficult relationship with the web’s programming language, these have proven invaluable.

Properly Labelling Elements

A good amount of accessibility comes down to labelling things that rely on visual appearance alone to convey meaning. Much like the alt attribute allows us to describe images, aria-label (and its relations) extend this ability to other elements.

Navigation component that allows users to move between articles in a series.

Here is the markup I was using in the navigation element that allows users to traverse previous and next articles within a series:

<div class="c-traverse-nav"> <a rel="prev" href="/2016/we-need-to-talk-about-technical-debt/" data-sequence-title="We Need to Talk About Technical Debt"> <svg width="20" height="20" viewBox="0 0 200 200" role="img"> <path d="M50 100l85 85 7-7-78-78 78-78-7-7"/> </svg> <span class="u-hidden">Previous article</span> </a> <a rel="next" href="/2016/what-the-heck-is-inclusive-design/" data-sequence-title="What the Heck Is Inclusive Design?"> <span class="u-hidden">Next article</span> <svg width="20" height="20" viewBox="0 0 200 200" role="img"> <path d="M150 100l-85 85-7-7 78-78-78-78 7-7"/> </svg> </a> </div>

While I had provided text content for these links, this component still had a number of issues:

  • No indication was given as to the role these links play and their relationship to each other.
  • Using role='img' on the SVG icons, but not providing any accessible names, was akin to including images without alt attributes.
  • Useful information, in this case the title of the previous and next article, was hidden within a data- attribute. This attribute was used in the stylesheet to add content that is shown in animated ‘flaps’ that appear on hover:
.c-traverse-nav a[rel=prev]:hover::after { content: 'Previous: \A' attr(data-sequence-title); } .c-traverse-nav a[rel=next]:hover::after { content: 'Next: \A' attr(data-sequence-title); }

Meaningful content in CSS? That should have been a red flag. I revised this component as follows:

<nav class="c-traverse-nav" aria-label="Articles"> <a rel="prev" href="/2016/what-the-heck-is-inclusive-design/" aria-label="Previous: We Need to Talk About Technical Debt"> <svg width="20" height="20" viewBox="0 0 200 200" focusable="false" aria-hidden="true"> <path d="M50 100l85 85 7-7-78-78 78-78-7-7"/> </svg> </a> <a rel="next" href="/2016/what-the-heck-is-inclusive-design/" aria-label="Next: What the Heck Is Inclusive Design?"> <svg width="20" height="20" viewBox="0 0 200 200" focusable="false" aria-hidden="true"> <path d="M150 100l-85 85-7-7 78-78-78-78 7-7"/> </svg> </a> </nav>

The first thing I did was give this set of links a label. I originally choose Articles navigation. However, in testing VoiceOver would announce: navigation, Articles navigation. As the nav element already describes the role, we need only provide additional information about the type of navigation this is.

Secondly, on the advice of Francis, I added focusable='false' to all inline SVG markup. This is due to a bug in IE11 where SVGs are keyboard focusable by default.

Regarding the labelling of the SVG icons, I had two choices. I could either move the hidden text content to these icons using aria-label, or remove them from the accessibility tree entirely using aria-hidden. In considering the second option, I realised I could merge the hidden text with that in the data- attribute, and use this combined information within an aria-label attribute. All of a sudden, my CSS became much simpler:

.c-traverse-nav a:hover::after { content: attr(aria-label); }

Accessible markup is useful markup.

Considering the Aural Experience

Navigating the site using a screen reader lead to me making a few other small changes as well. For example, a few links on the site include a right-pointing arrow, a visual flourish created using the following CSS:

.c-continue::after { content: ' \203A'; /* Single Right-Pointing Angle Quotation Mark */ }

However, screen-readers typically announce generated content. When these links were read out, you’d hear nonsense like this:

link, more articles by drew single right-pointing angle quotation mark.

Adding speak: none had no effect (CSS aural properties have little support). However, I could create a similar arrow using CSS borders:

.c-continue::after { display: inline-block; vertical-align: middle; height: 0.375em; width: 0.375em; border: 0.1875em solid; border-color: currentColor currentColor transparent transparent; transform: rotate(45deg); content: ''; } Continue links before and after improvements. While they look similar, the revised design sounds much better.

I also made improvements to the styling of author names in article summaries. Originally, these were distinguished from the rest of the excerpt by styling them as uppercase text. Francis pointed out that some screen readers will spell out uppercase letters (regardless of whether they appear in the HTML or have been altered by CSS) if they don’t spell a known word. For example VoiceOver and NVDA have trouble with Chris Coyier's surname, so his name would be read aloud as Chris C-O-Y-I-E-R. The simple fix was to distinguish names using emboldened text instead.

If I'm honest, I’ve been somewhat arrogant in the past, thinking that by using semantic markup and progressive enhancement, I needn’t worry too much about accessibility. While using the right elements, and considering an interface not only in visual terms is important, this is the absolute bare minimum. An understanding of different assistive technologies, and willingness to test with them, is just as important.

Reviewing General Usability

Thinking about accessibility led to me improve overall usability, too.

For this years set of articles, we no longer link to author's websites from article excerpts. This historical holdover was poorly resolved previously; if you happened to click on the author’s name you would be taken to their website, not the article as you would expect. We also included comment counts that were linked to the comment section on the article page (which itself linked to a separate comments page). Madness!

Now, each article has one link; to the article. A home page that once involved tabbing through 24×3 links, is now less noisy and much easier to navigate for everyone.

Other refinements included ensuring the site is responsive in terms of height, as well as width, ensuring the navigation menu can be dismissed when you click outside of it, and a review of overall performance. These might not be considered accessibility improvements, but I’m not so sure. To suggest this would be to think accessibility is an entirely separate concern. In fact, making changes that benefit one set of users will typically benefit all.

Creating something new will always attract attention and admiration, but there’s an under-celebrated nobility in improving what already exists. While not all changes may be visual, they can have just as much impact. I know that, had we decided to redesign the site this year, many of these improvements would not have been made. Hopefully, this overview will encourage you to look at your own projects and think about similar changes you might make.

Having a growing awareness of the issues, and expanding your knowledge of the tools available is an essential requirement of working on the web. However, don’t keep that knowledge saved up for the future; if you can, go back and fix your older projects too.

Improving the Accessibility of 24 ways is a post from CSS-Tricks

Categories: Web Technologies

Using Composer packages with OpenWhisk - Rob Allen

Planet PHP - Wed, 01/03/2018 - 03:03

When creating new OpenWhisk actions in PHP, It's likely that you'll want to take advantage of the rich ecosystem of Composer packages on Packagist.org.

The OpenWhisk PHP runtime has you covered with some pre-installed Composer packages and also the ability to upload your own using a zip file.

Pre-installed Composer packages

The PHP runtime ships with two Composer packages by default: Guzzle and ramsey/uuid.

This is handy as if you need to make an API call from your action, then you have the full power to Guzzle at your fingertips. The ramsey/uuid library is also handy for those times when you need a UUID when PUT'ing to that API.

If you need anything else then you have to do a bit more leg work.

Uploading your own project files

The PHP runtime also accepts a zip file when creating or updating an action. This means that you can create a PHP project for your action that includes a composer.json.

For example, let's say that you want to use NFNumberToWord in your action.

Create the PHP project

Firstly, create the composer.json file:

$ composer require nineteenfeet/nf-number-to-word

This creates composer.json, composer.lock and a vendor directory with the component and autoloader code in it.

We now need an action file. This must be called index.php:

index.php:

<?php use NFNumberToWord\NumberToWords; function main(array $args) : array { if (!isset($args['number'])) { return ['error' => 'Please supply a number.']; } $number = (int)($args['number']); $words = (new NumberToWords)->toWords($number); return [ 'result' => "$number in words is: $words", 'words' => $words, ]; }

The main function takes an associative array of arguments and must return an associative array which is converted to JSON for us. As with any other library, we import it using a use statement and can then instantiate the class and call toWords() on it.

Note that we don't need to include the Composer autoload file as this is done automatically by the PHP runtime.

Upload to OpenWhisk

To upload to OpenWhisk we first zip up the files and then use the wsk command line client to create the action:

$ zip -q -r n2w.zip index.php vendor

The name of the zip file is immaterial, so I've used something simple. Now we upload it to OpenWhisk:

$ wsk action update n2w n2w.zip --kind php:7.1

In this case, I've named the action n2w and passed in the zip file we have just created and specified the runtime to use with the --kind parameter. This is needed because we are supplying a zip file as our action code and OpenWhisk need to know which runtime to use for it.

That's it. We're done.

Running our action

We can prove it worked using:

$ wsk action invoke -r n2w -p number 12345

This outputs:

{ "result": "12345 in words is: twelve thousand, three hundred and forty-five", "words": "twelve thousand, three hundred and forty-five" }

Fin

As you can see, it's really easy to take advantage of the vast library of Packagist components in your actions, but of course, if all you need is an HTTP client, then Guzzle is already available.

Categories: Web Technologies

Top 4 Reasons Companies Won't Fix Their Database Issues

Planet MySQL - Wed, 01/03/2018 - 02:00
When I consult at a company, I aim to identify issues with their database and give options on how to solve them.
However, sometimes implementing those solutions may be a more lengthy process than it needs to be and sometimes they may not be implemented at all. During my career, I have observed some reasons as to why that might happen within organizations.

Obviously, the following observations will never happen at your company. I am just writing about them so that you might notice them in other places.

1. Legacy code 
People don't like to have anything to do with legacy code. It’s painful. It’s difficult. It’s risky to change. It runs business critical functions. Worse of all, they didn’t write it. This can be a problem as often, the most cripling database issues require changes to legacy code.

2. New Technologies or Methods
People don’t like you to introduce any new technologies they don’t want to learn and maintain. Not even different methods in technologies already being used. No fancy upgrades to the DB server, no new load balancers and certainly don’t start using SQL statements in the code over their existing ORM.

3. Old Technologies or Methods
In a complete polar opposite, people in tech organisations don’t like you to introduce boring technologies. What would be the point of introducing boring (yet tested) technologies when they could be playing around with shiny new ones. There is a caveat to this - groups prefer it when other groups they depend on (let’s say developers depend on ops) choose to use boring and tested technologies. Just not for themselves. And vice versa.

4. Management Involvement
Last, but certainly not least, no one from upper management will get involved in resolving these issues and push forward solutions. No project/product manager/agile-coach will be assigned to chase up issues. As far as they are concerned, this is an engineering issue and as engineers, you need to sort it out yourselves. Only 'change requests' from the business, have managers around it.


Final Thoughts
After some years of analysing database systems for performance issues, I am finally realising that I should also analyse human systems for performance issues.


Categories: Web Technologies

Build Uber App with Node JS

Echo JS - Wed, 01/03/2018 - 01:38
Categories: Web Technologies

Create a Music App JavaScript

Echo JS - Wed, 01/03/2018 - 01:38
Categories: Web Technologies

An update on Write Set (parallel replication) bug fix in MySQL 8.0

Planet MySQL - Tue, 01/02/2018 - 22:00
In my MySQL Parallel Replication session at Percona Live Santa Clara 2017, I talked about a bug in Write Set tracking for parallel replication (Bug#86078).  At the time, I did not fully understand what was going wrong but since then, we (Engineers at Oracle and me) understood what happened and the bug is supposed to be fixed in MySQL 8.0.4.  This journey thought me interesting MySQL behavior and
Categories: Web Technologies

Pages