emGee Software Solutions Custom Database Applications

Share this

Web Technologies

When Your JSON Key is Numeric

Planet MySQL - Tue, 05/22/2018 - 16:01
There was an interesting question on Stackoverflow.com on extracting values from a JSON data type column in a MySQL database.  What caught my eye was the the keys for the key/value pairs were numeric. In particular the author of the question only wanted values for the key named 74.  The sample data was fairly simple.

{ "70" : "Apple", "71" : "Peach", "74" : "Kiwi" }

I thought SELECT JSON_EXTRACT(column, '$.74') FROM table; should work but it did not. There was a complaint about an invalid path expression.

It turns out that you need to make the second argument in the function '$."74"' or SELECT JSON_EXTRACT(column,'$."74"') FROM table; 

File this under something to remember for later. :-)
Categories: Web Technologies

Percona Toolkit 3.0.10 Is Now Available

Planet MySQL - Tue, 05/22/2018 - 13:32

Percona announces the release of Percona Toolkit 3.0.10 on May 22, 2018.

Percona Toolkit is a collection of advanced open source command-line tools, developed and used by the Percona technical staff, that are engineered to perform a variety of MySQL®, MongoDB® and system tasks that are too difficult or complex to perform manually. With over 1,000,000 downloads, Percona Toolkit supports Percona Server for MySQL, MySQL®, MariaDB®, Percona Server for MongoDB and MongoDB.

Percona Toolkit, like all Percona software, is free and open source. You can download packages from the website or install from official repositories.

This release includes the following changes:

New Features:
  • PT-131: pt-table-checksum disables the QRT plugin
    The Query Response Time Plugin provides a tool for analyzing information by counting and displaying the number of queries according to the length of time they took to execute. This feature enables a new flag --disable-qrt-plugin  that leverages Percona Server for MySQL’s new ability to disable QRT plugin at the session level. The advantage to enabling this Toolkit feature is that the QRT metrics are not impacted by the work that pt-table-checksum performs. This means that QRT metrics report only the work your Application is generating on MySQL, and not clouded by the activities of pt-table-checksum.
  • PT-118: pt-table-checksum reports the number of rows of difference between master and slave
    We’re adding support for pt-table-checksum to identify the number of row differences between master and slave. Previously you were able to see only the count of chunks that differed between hosts. This is helpful for situations where you believe you can tolerate some measure of row count drift between hosts, but want to be precise in understanding what that row count difference actually is.
  • PT-1546: Improved support for MySQL 8 roles
  • PT-1543: The encrypted table status query causes high load over multiple minutes
    Users reported that listing encrypted table status can be very slow.  We’ve enabled this functionality via --list-encrypted-tables and set it to default of disabled.
  • PT-1536: Added info about encrypted tablespaces in pt-mysql-summary
    We’ve improved pt-mysql-summary to now include information about encrypted tablespaces.  This information is available by using --list-encrypted-tables .
Bug Fixes:
  • PT-1556: pt-table-checksum 3.0.9 does not change binlog_format to statement any more.

pt-show-grants has several known issues when working with MySQL 8 and roles, which Percona aims to address in subsequent Percona Toolkit releases: PT-1560PT-1559, and PT-1558

Help us improve our software quality by reporting any bugs you encounter using our bug tracking system.

The post Percona Toolkit 3.0.10 Is Now Available appeared first on Percona Database Performance Blog.

Categories: Web Technologies

New Stats Exposed in Go's database/SQL Package

Planet MySQL - Tue, 05/22/2018 - 13:18

If you’re someone who keeps up with the Go development cycle, then you’ll know that a couple of weeks ago Go entered its feature-freeze for the Go 1.11 release. One of the changes for this upcoming release that caught my eye was to the database/sql package. Daniel Theophanes contributed a change that introduces several new counters available via the DB.Stats() method.

If you’re not familiar with it, DB.Stats() returns a DBStat structure containing information about the underlying sql.DB that the method is called on. Up to this point, the struct has had a single field, tracking the current number of open connections to the database. Daniel’s patch introduces a number of additional fields though:

  • MaxOpenConnections: The max allowed open connections to the DB, as set by DB.SetMaxOpenConns.
  • InUse: The number of connections actively in-use.
  • Idle: The number of open connections that are currently idle.
  • WaitCount: The total number of times that a goroutine has had to wait for a connection.
  • WaitDuration: The cumulative amount of time that goroutines have spent waiting for a connection.
  • MaxIdleClosed: The number of connections closed according to the limit specified by DB.SetMaxIdleConns.
  • MaxLifetimeClosed: The number of connections closed because they exceeded the duration specified by DB.SetConnMaxLifetime.

Note that of the above fields, WaitCount, WaitDuration, MaxIdleClosed and MaxLifetimeClosed are all counters; that is to say, their values never decrease over the lifetime of the DB object, they only increase over time.

The new stats will be available when Go 1.11 is released, which is projected to be available in August. In the meantime, if you aren’t publishing DBStats metrics in your applications today you can work on adding it to integrate into a metrics collector such as Graphite, Prometheus, or even VividCortex. The call to DB.Stats() is cheap and thread-safe, so it’s fairly easy to spawn another goroutine to call it periodically and forward the data to a metrics collector of your choice.

The new information here makes the DB.Stats() command much more useful for monitoring the behavior of database connections. In particular, as noted by Daniel in the commit message, if you see a high amount of waiting or closed connections it may indicate that you need to tune the settings for your DB object. I’ll be adding new metrics to our applications once we upgrade to Go 1.11, you should add them to yours as well!

Can't get enough Go? Check out our free eBook The Ultimate Guide to Building Database-Driven Apps with Go, our free webinar Developing MySQL Applications with Go, or sharpen your skills with the Go database/sql package tutorial

Ready, set, Go!

Categories: Web Technologies

Just a Couple’a Fun Typography Links

CSS-Tricks - Tue, 05/22/2018 - 13:10

The post Just a Couple’a Fun Typography Links appeared first on CSS-Tricks.

Categories: Web Technologies

Learning Gutenberg: A Primer with create-guten-block

CSS-Tricks - Tue, 05/22/2018 - 07:01

Welcome back! We’ve just taken a look at what Gutenberg is and how it operates from the admin side. Gutenberg is certainly going to have a massive impact on the WordPress world. If you are just arriving here and have no idea what we’re talking about, I recommend at least skimming Part 1 to make sure you have the appropriate background.

Let’s create a custom block with a bit of help from a wonderful tool called create-guten-block. Onward!

Article Series:
  1. Series Introduction
  2. What is Gutenberg, Anyway?
  3. A Primer with create-guten-block (This Post)
  4. Modern JavaScript Syntax (Coming Soon!)
  5. React 101 (Coming Soon!)
  6. Setting up a Custom webpack (Coming Soon!)
  7. A Custom "Card" Block (Coming Soon!)
Blocks live in plugins

To create a Gutenberg block, you create a WordPress plugin. Anything that affects *content*, like a Gutenberg block certain will, needs to be a plugin so that it remains active even as you change themes. Something that is very theme-specific or just affects how your site looks can be part of the theme files or functions.php file in your theme. Read more about this distinction in our article about WordPress Functionality Plugins.

That said, the blocks in themes issue is a hot topic. The WordPress Theme Review Team is discussing whether or not to allow blocks in themes at all as part of themes. A post, “Getting Ready for Gutenberg”, on the Theme Review Team’s Make page posed this question, and was met with strong opinions from both sides. The general consensus, however, is that blocks are plugin territory.

WordPress.org is comprised of various teams, each with their own homepage at make.wordpress.org/team-name, channel in the WordPress Slack, and a weekly meeting. If you are interested in getting involved in WordPress or curious about how it operates, I highly recommend browsing through a list of the teams here, joining a Slack channel, and popping into a weekly meeting to see how it all happens.

In the far future, it’s possible that themes will consist of *just a stylesheet*, while all custom functionality and content structure come from blocks in plugins. I'm paraphrasing the words of Tammie Lister, Gutenberg's design lead, on this episode of Shoptalk Show. Very much worth a listen!

Taking a setup shortcut... for now

What’s kept me from diving head first into modern JavaScript is the dang configuration. The transpiling, the bundling, the code splitting, the tree shaking... yeesh, I’m busy! I love learning new things, but there’s a limit to my patience and, apparently, configuring a build process for a small test project is my limit.

It’s this sentiment that led to the development of a tool called create-react-app, zero-configuration build setup for, you guessed it, creating React apps. It’s brilliant. Assuming you have a functioning node and npm installation, you can run a single command and you have a project ready for you to start coding in React. The transpiling, bundling, and tree shaking is set up for you.

But wait... can we use create-react-app for Gutenberg blocks? No, but the aforementioned create-guten-block, developed and beautifully documented by Ahmad Awais, does pretty much the same thing for us! That’s what we’ll be using for our block.

create-guten-block is not the only block generating tool at our disposal! You can scaffold a block using WP-CLI, but I have chosen not to because the default setup is for ES5 (for now) and does not give us what we need for our journey into modern JavaScript. That being said, I found it helpful to dig through the ES5 implementation of a block as a way to reinforce the core concepts, so maybe give it a go after you finish here!

Yes, this is a shortcut. We are choosing to avoid understanding the core concepts of a technology by using a tool. We’ll have to learn these concepts someday. But for now, I’m totally fine bypassing this configuration step. My philosophy about using tools such as this: use them, but do so with the understanding that it *probably* won't save you time or effort in the long run.

It's worth noting that, like create-react-app, create-guten-block allows you to npm eject your configuration. This means exposing all of the settings the tool has created for us and making them available for customization. Note, however, that this is irreversible; if you eject and then make a mistake, you’re on your own to fix it! Like I said, you'll have to learn it someday :)

Step 1: Install create-guten-block

We will first install create-guten-block globally, like so:

npm install -g create-guten-block

In theory this should work no problem, but that's not realistic. create-guten-block requires a minimum of Node version 8 and npm 5.3, so if you haven’t updated either of them for a while, that’s one possible error (and here’s one possible solution).

I always start by pasting my console error into a search engine and removing line numbers and file names to keep my query general. In the interest of improving this tutorial, however, I am curious to hear about what went wrong so feel free to post your issue in the comments as well.

Step 2: Create that guten-block

It’s time! Let’s do it! You know what? I’m not going to tell you how because Ahmad’s documentation is so good and there’s no sense in replicating it.

Go here and follow Ahmad’s instructions to create that guten-block in your command line.

You should see something like this when running the command, create-guten-block test, where “test” is the name of my block. Step 3: Activate the plugin

Go to your Plugins screen, activate your new block plugin — it should be called something like test-block — CGB Gutenberg Block Plugin where "test-block" is what you named your block when creating it.

Step 4: That's it! Let’s use our custom block!

So easy! Now, go to the editor view of a post or page, locate your block, and insert it.

Although I named my block “test”, searching “test” in the block selector yielded the wrong result as you can see in the gif above. The default name of the block is instead “CGB Block” — we will change this very soon!

Text editor setup (optional)

I’ve found it very helpful to have a specific text editor setup for developing blocks. I use Visual Studio Code for my text editor, but I’m sure you can figure out something similar with whatever editor is your preference.

Here are the key ingredients:

  1. Easy access to the command line to keep an eye on build errors (there will be build errors)
  2. A copy of the Gutenberg source from GitHub for code reference (download or clone it here)
  3. Easy access to both your plugin’s directory and Gutenberg’s source directory from #2
​​My VS Code setup for Gutenberg development. Notice the integrated terminal and multiple source directories on the right.

In VS Code, I accomplish this using the following features:

  1. The integrated terminal — open with Command + ~ on Mac, or from the menu bar with View > Integrated Terminal
  2. A Workspace containing folders for both your plugin and Gutenberg’s source from GitHub. You can doing this by opening your plugin directory in VS Code, then choosing File > Add Folder to Workspace and selecting the Gutenberg directory you downloaded from the GitHub repo. You can then save the Workspace for easy access with File > Save Workspace As (I called mine “Blocks” in the image above).

This part is optional, and you don’t have to use VS Code. The important thing is having ready access to the command line, your plugin’s source, and the Gutenberg plugin’s source for reference. You can totally reference the source on GitHub if you like, but I enjoy having the files in the same environment for side-by-side comparison and easy searching with Find In Folder.

We are using Gutenberg from the plugin repository for the actual functionality, but that instance only includes the compiled files. We want to reference the source files, so we need to use the codebase directly from GitHub. If you'd like to access updates before they are released in the plugin, you can clone the repository. It would be totally possible to build and work from the GitHub version, but for simplicity’s sake, we are using the plugin version in this tutorial.

Once you are ready to go, make sure you are cd'd into your block’s plugin folder and run npm start. You should see a satisfying message indicating the process has started:

After running npm start in our plugin folder, we are officially “Watching for changes…” (and we didn’t have to touch any config! Cheaters...)

I’m using Wes Bos’s theme for Cobalt 2 in VS Code as well as the same theme for ZSH in my Terminal and iTerm. This makes absolutely no difference in how the technology works, but it does make a difference, on a personal level, to customize your workspace and make it feel like your own (or Wes Bos’, in my case).

What's what

Now that we are in code mode, let’s take a look at the files we’ll be working with. I’ll borrow this from the create-guten-block Readme for reference:

└── test-block ├── plugin.php ├── package.json ├── README.md | ├── dist | ├── blocks.build.js | ├── blocks.editor.build.css | └── blocks.style.build.css | └── src ├── block | ├── block.js | ├── editor.scss | └── style.scss | ├── blocks.js ├── common.scss └── init.php

For the purposes of this tutorial, we are only concerned with what is inside the src directory. We will not touch anything in dist (those are compiled files), plugin.php, or any stragglers such as package.json, package-lock.json, or.eslintignore.

plugin.php officially alerts WordPress of our plugin’s existence. It requires src/init.php, which is where we’ll write any PHP we need for our block(s). In general, we won’t write anything in plugin.php — out of the box, the only code it contains are the comments to register our plugin.

Let’s drill into src:

└── src ├── block | ├── block.js | ├── editor.scss | └── style.scss | ├── blocks.js ├── common.scss └── init.php

The block directory contains files for single, individual block. This includes:

  • block/block.js — All the JavaScript for the individual block.
  • block/editor.scss — Sass partial for styles specific to the editor view,
  • block/style.scss — Sass partial for styles specific to the front-end view, i.e. what you see when you view your page/post.

Now, open up src/blocks.js:

I think of src/blocks.js as a table of contents for blocks, similar to the role of an index.scss or main.scss in a Sass project structure. If we wanted to include two blocks in our plugin — let’s say this was a suite of custom blocks — we could, in theory, duplicate the block directory, rename it, and add something like this to src/blocks.js:

import 'new-block/block.js';>

Then, whatever create-guten-block has prepared for us behind the scenes would know to include our new block's block.js in the main script file compiled into dist (now is a good time to take a peek into dist, if you haven't already).

Not too bad so far, right? We still haven't really gotten to any JavaScript...

A challenge!

Okay, now it’s time for a challenge! Open up src/block/block.js and take a couple of minutes to read through the author, Ahmad’s, excellent comments.

Then, see if you can figure out how to*:

  1. Change the name of your block, that is, the one that shows in the block selector
  2. Change the icon of your block (❤ Dashicons)
  3. Change the text that displays on the front end i.e. when you “View Post”
  4. Change the text that displays on the back end i.e. editor view
  5. Give the front end view a border radius of 30px
  6. Give the editor view a gradient background
  7. Make the text in first paragraph tag editable

* You should be able to work through (almost!) all of these in about 10 minutes. ;-)

How was that?

What problems did you run into? Did you get tired of reloading the editor? Did you see the “This block appears to have been modified externally” message more often than you’d like? I sure did, but such is life with new technology — there's a lot to be desired in the developer experience, but this isn't a priority for the team at present and will come in the later stages of Gutenberg's planned development.

Most importantly, did you get #7?

If you did, then you should be writing this tutorial! That one was a gotcha. I hope you felt at least a little confused and curious because that’s how we learn! We’ll get to that in Part 3.

Now that we have our bearings, let's dig deeper into this notion of a block.

Skeleton of a block

Here is block.js with the comments stripped out — what we might call the skeleton of a static block:

// Stripped down version of src/block/block.js // PART 1: Import dependencies import './style.scss'; import './editor.scss'; // PART 2: Setup references to external functions const { __ } = wp.i18n; const { registerBlockType } = wp.blocks; // PART 3: Register the block! registerBlockType( 'cgb/block-test', { // Part 3.1: Block settings title: __( 'test - CGB Block' ), icon: 'shield', category: 'common', keywords: [ __( 'test &mdash; CGB Block' ), __( 'CGB Example' ), __( 'create-guten-block' ), ], // PART 3.2: Markup in editor edit: function( props ) { return ( <div>You’ll see this in the editor</div> ); }, // PART 3.3: Markup saved to database save: function( props ) { return ( <div>This is saved to the database and returned with the_content();</div> ); }, } );

Let’s do a side-by-side comparison with another static block, the “Separator” block from the default blocks included in Gutenberg. That file is is located in gutenberg/blocks/library/separator/index.js. If you have the folder open in either VS Code or Sublime, you can use the shortcut Command + Option + 2 on a Mac, or View > Split Editor to get the files side-by-side.

If you are following the text editor setup outlined previously, you should have something like this:

In this image, I copy/pasted the above stripped-down version of the block into an empty file to compare it without the comments. That's optional!

What similarities do you notice? What differences? Open up a few of the other block directories inside gutenberg-master/library/, and take a peek into their files, comparing them to our block skeleton. Spend a few minutes reading the code and see if you can spot some patterns.

Here are a few patterns I noticed:

  1. There are curly braces in variable declarations and function arguments all over the place.
  2. Markup appears inside of return statements and often contains made-up tag names (you might recognize these as React components).
  3. All blocks seem to have a settings object containing entires for title, icon , category, etc. In the library blocks, they appear in an export const settings = ... object, whereas in our plugin block, they are part of an argument for registerBlockType.
  4. All blocks have functions for edit and save as part of the settings object.
    • The syntax for the functions is slightly different than our block’s editand save functions:
      • edit( { className } ) { ... } in separator/index.js
      • edit: function(props) { ... } in our block.js
    • The library blocks appear to reference attributes and instead of props
  5. All blocks in the library contain an index.js. Some contain a block.js or other files that appear to contain a definition for a class extending a Component, e.g. class LatestPostsBlock extends Component { ....

What did you find? Feel free to contribute in the comments (but don't stop reading here!).

A somewhat brief and relevant tangent

You probably noticed a statement importing @wordpress/i18n in every index.js and block.js file in the library, as well as a reference to wp.i18n in our plugin’s block.js. i18n stands for internationalization just like a11y stands for accessibility. Internationalization refers to the practice of developing your application to be easily translated to other languages. Since we want to prepare all static text in our blocks for translation, we assign wp.i18n to an alias of __for brevity, very much like we use the $ as an alias for good ‘ol jQuery. Read more about i18n for WordPress here

It’s also worth mentioning where that wp in wp.i18n is coming from and why it’s referenced as @wordpress/i18n in the Gutenberg source. wp is a global object — global meaning a variable available everywhere — containing all of WordPress’ publicly available JavaScript API methods. To demonstrate this, open up the console while on a page within the WordPress admin. Type wp and hit Enter. You should see something like this:

So, anytime we reference something within that wp object, all we are doing is accessing some functionality the WordPress JavaScript API provides us. @wordpress/i18n in the Gutenberg source is doing the same thing, but its importing the functions from an npm module rather than the global object. The functions in the wp global have been intentionally exposed to the public API by the WordPress core developers for use in themes and plugins.

If you are anything like my internal critic, you might be thinking, “Whatever, Lara, I don’t care about those details. Just tell me how to make a cool block with all the JavaScript already!” To which I would reply:

There are so many moving parts and new concepts in this environment that, I’ve found, the more code I take for granted, the more frustrating and time-consuming the process becomes. Approach every line of code with curiosity! If you don’t know what it does, do a Find in Folder in the Gutenberg source and see if you can find a trail to follow. For me, at least, this has been a much more enjoyable way to approach unfamiliar code than trying to build something haphazardly with copy and paste.

And with that, let’s wrap up Part 2!


What? Homework? Heck yes, there is homework! In Part 3, Andy &#x1f349; will dive into modern JavaScript goodies: React, JSX, and ES6 syntax. Although our series is written for those relatively new to JavaScript, it is helpful to learn the code and the concepts from many different angles and resources.

In an effort to introduce some concepts early on, here is an outline for some “Homework” prior to Part 3:

1. Spend some time (1-2 hours) on a React tutorial, or until you can explain in your own words:
  • The render method in React
  • JSX and that those made-up tag names map to JavaScript functions
  • Why React uses className instead of class

Recommended resources:

I'd also recommend reading React State from the Ground Up here on CSS-Tricks, by Kingsley Silas, because it specifically dives into state in React. If you are brand new to React, this will be a lot to digest, but I think it's worth getting it into your brain ASAP even if it doesn't make sense quite yet.

2. Understand ES6 Destructuring and find a few examples of it in both the Gutenberg source and our plugin (that won’t be hard).

Recommended resources:

3. Be comfortable with conditional or ternary operators.

In a sentence, ternary operators are shorthand for if...else statements. You’ll see these all over the Gutenberg source — find some simple examples that provide a fallback for a string’s value, as well as more robust uses like in blocks/library/paragraph/index.js, for example.

Recommended resources:

  • The MDN article is very good.
  • Also look into the not not operator — here is a Stack Overflow post about it.
  • Not to get too far down this rabbit hole, but if you are extra ambitious, do some research about type coercion in JavaScript. This article on FreeCodeCamp and this chapter from You Don’t Know JS by Kyle Simpson are solid starting points.

Okay! Thank you so much for reading, and see you in Part 3 for React, JSX, and other goodies.


Was there any part of this tutorial that didn't make sense? Did you get lost anywhere? We'd love to keep making this better, so please let us know if any part of this was hard to follow or if any information is incorrect or out of date.

Thank you, again, and good luck!

Article Series:
  1. Series Introduction
  2. What is Gutenberg, Anyway?
  3. A Primer with create-guten-block (This Post)
  4. Modern JavaScript Syntax (Coming Soon!)
  5. React 101 (Coming Soon!)
  6. Setting up a Custom webpack (Coming Soon!)
  7. A Custom "Card" Block (Coming Soon!)

The post Learning Gutenberg: A Primer with create-guten-block appeared first on CSS-Tricks.

Categories: Web Technologies

​Build live comments with sentiment analysis using Nest.js

CSS-Tricks - Tue, 05/22/2018 - 06:59

(This is a sponsored post.)

Interestingly, one of the most important areas of a blog post is the comment section. This plays an important role in the success of a post or an article, as it allows proper interaction and participation from readers. This makes it inevitable for every platform with a direct comments system to handle it in realtime.

In this post, we’ll build an application with a live comment feature. This will happen in realtime as we will tap into the infrastructure made available by Pusher Channels. We will also use the sentiment analysis to measure whether comments are positive or negative, and display this information on an admin panel.

Direct Link to ArticlePermalink

The post ​Build live comments with sentiment analysis using Nest.js appeared first on CSS-Tricks.

Categories: Web Technologies

Atlas.Query: Simple. Sensible. SQL. - Paul M. Jones

Planet PHP - Tue, 05/22/2018 - 05:00

I am happy to announce that Atlas.Query is now stable and ready for production
use! Installaton is as easy as composer require atlas/query ~1.0.

With Atlas.Query and any PDO instance, you can build and execute your queries in a single fluent series of method calls:

use Atlas\Query\Select; $rows = Select::new($pdo) ->columns('*') ->from('posts') ->where('id IN ', $ids) ->fetchAll(); foreach ($rows as $row) { // ... }

If you prefer, you can exercise fine control over your PDO connection, use a query factory, or build your queries in smaller steps:

use Atlas\Pdo\Connection; use Atlas\Query\QueryFactory; $connection = Connection::new( 'mysql:host=localhost;dbname=testdb', 'username', 'password' ); $queryFactory = new QueryFactory(); $select = $queryFactory->newSelect($connection); $select->columns('*'); $select->from('posts'); $select->where('id = ', $id); $row = $select->fetchOne();

Atlas.Query provides the full power of SQL at your fingertips …

$select ->columns(...) ->from(...) ->join(...) ->where(...) ->groupBy(...) ->having(...) ->orderBy(...) ->limit(...) ->offset(...);

… along with UNIONs, paging, sub-selects, inline value binding, and all sorts of fetch and yield styles.

Atlas.Query comes with INSERT, UPDATE, and DELETE builders as well:

use Atlas\Query\Insert; $insert = Insert::new($pdo); // insert a row ... $insert->into('posts') ->columns([ 'title' => $title, 'body' => $body, ]) ->raw('created_at', 'NOW()') ->perform(); // ... and get back the autoincrement value: $post_id = $insert->getLastInsertId();

Do you work on different project with different datbase backends? Atlas.Query lets you use the same interface for them all, while not restricting you to a common subset of functionality. MySQL, PostgreSQL, SQLite, and SQL Server are all supported explicitly.

And if you discover you need more than just a query system, you’ll have a clear refactoring path towards Atlas.Orm. If you are looking for a modern, stable, easy-to-use query system, try Atlas.Query in your project!

Categories: Web Technologies

Testing React Apps with Cypress

Echo JS - Tue, 05/22/2018 - 03:12
Categories: Web Technologies

MySQL 8.0: MVCC of Large Objects in InnoDB

MySQL Server Blog - Tue, 05/22/2018 - 02:58

In this article, I’ll explain about the multi version concurrency control (MVCC) of large objects (LOBs) design in the MySQL InnoDB storage engine.  MySQL 8.0 has a new feature that allows users to partially update large objects, including the JSON documents.  …

Categories: Web Technologies

MySQL 8.0: MVCC of Large Objects in InnoDB

Planet MySQL - Tue, 05/22/2018 - 02:58

In this article, I’ll explain about the multi version concurrency control (MVCC) of large objects (LOBs) design in the MySQL InnoDB storage engine.  MySQL 8.0 has a new feature that allows users to partially update large objects, including the JSON documents.  …

Categories: Web Technologies

MySQL master discovery methods, part 6: other methods

Planet MySQL - Tue, 05/22/2018 - 01:39

This is the sixth in a series of posts reviewing methods for MySQL master discovery: the means by which an application connects to the master of a replication tree. Moreover, the means by which, upon master failover, it identifies and connects to the newly promoted master.

These posts are not concerned with the manner by which the replication failure detection and recovery take place. I will share orchestrator specific configuration/advice, and point out where cross DC orchestrator/raft setup plays part in discovery itself, but for the most part any recovery tool such as MHA, replication-manager, severalnines or other, is applicable.

Hard coded configuration deployment

You may use your source/config repo as master service discovery method of sorts.

The master's identity would be hard coded into your, say, git repo, to be updated and deployed to production upon failover.

This method is simple and I've seen it being used by companies, in production. Noteworthy:

  • This requires a dependency of production on source availability.
    • The failover tool would need to have access to your source environment.
  • This requires a dependency of production on build/deploy flow.
    • The failover tool would need to kick build, test, deploy process.
  • Code deployment time can be long.
  • Deployment must take place on all relevant hosts, and cause for a mass refresh/reload.
    • It should interrupt processes that cannot reload themselves, such as various commonly used scripts.
Synchronous replication

This series of posts is focused on asynchronous replication, but we will do well to point out a few relevant notes on sychnronous replication (Galera, XtraDB Cluster, InnoDB Cluster).

  • Synchronous replication can act in single-writer mode or in multi-writer mode.
  • In single writer mode, apps should connect to a particular master.
    • The identity of such master can be achieved by querying the MySQL members of the cluster.
  • In multi-writer mode, apps can connect to any healthy member of the cluster.
    • This still calls for a check: is the member healthy?
  • Syncronous replication is not intended to work well cross DC.

The last bullet should perhaps be highlighted. In a cross-DC setup, and for cross-DC failovers, we are back to same requirements as with asynchronous replication, and the methods illustrated in this series of posts may apply.

  • VIPs make less sense.
  • Proxy-based solution make a lot of sense.
All posts in this series
Categories: Web Technologies

Replication Test Coverage in MySQL 8.0

Planet MySQL - Tue, 05/22/2018 - 00:15

In the Replication QA team, we have been continuing to improve test coverage for Replication and Group Replication primarily to ensure that we support the newest and latest offerings of MySQL Server 8.0 such as Generated Columns, Set Persist, User Roles, and User Management DDLs that are now atomic.…

Categories: Web Technologies

Book review: Fifty quick ideas to improve your tests - Part 2 - Matthias Noback

Planet PHP - Mon, 05/21/2018 - 23:05

This article is part 2 of my review of the book "Fifty quick ideas to improve your tests". I'll continue to share some of my personal highlights with you.

Replace multiple steps with a higher-level step

If a test executes multiple tasks in sequence that form a higher-level action, often the language and the concepts used in the test explain the mechanics of test execution rather than the purpose of the test, and in this case the entire block can often be replaced with a single higher-level concept.

When writing a unit test for some complicated object, you may be collecting some data first, then putting that data into value objects, maybe wrapping them in other value objects, before you can finally pass them to the constructor of the value object. At that point you may have to call several methods on the object before it's in the right state. The same goes for acceptance tests. You may need quite a number of steps before you get to the point where you can finally write a 'When' clause.

I find that often the steps leading up to the 'When' clause (or to the 'Act' part of a unit test), can be summarized as one thing. This is meant by the "single higher-level concept". So instead of enumerating everything that has happened to the system, you look for a single step that described what your starting point is. For instance, instead of:

Given the user logged in And they have created a purchase order And they added product A to it, with a quantity of 10 And they placed the purchase order When the user cancels the purchase order Then ...

You could summarize the 'Given' steps as follows:

Given a placed purchase order for product A, with a quantity of 10 When the user cancels the purchase order Then ...

Once you start looking for ways to make things smaller and simpler, easier to follow and read, you'll find that many of the details you previously added to the smaller steps are completely irrelevant for the higher-level step. In our case, the product and the quantity may be completely irrelevant for the scenario that deals with cancelling the purchase order. So the final version may well be:

Given a placed purchase order When the user cancels the purchase order Then ...

When implementing the step definition for this single, simplified step, you still need to provide sensible default data. But it happens behind the scenes. This technique hides the details that are irrelevant, and only shows the relevant ones to the person reading the scenario. It will be a lot easier to understand what's being tested with this particular scenario.

I find that this approach works really well with unit tests too. One test case may show how a complicated object can be constructed, another test case won't just repeat all those steps, but will summarize it properly (like we did for the above scenario). This often requires the introduction of a private method in the test class, which wraps the individual steps. The method is the abstraction, its name the higher-level concept.

Specification, acceptance tests, living documentation

When creating your artifacts, remember the three roles they must serve at different times: now as a specification, soon as acceptance tests, and later as living documentation. Critique the artifact from each perspective. How well does it serve each distinct role? Is it over-optimised for one role to the detriment of others?

In workshops I often point out that testing is a crucial part of the development workflow. You need it to verify that the unit of code you've been working works as expected. To improve this perspective on writing tests, you could aim for not just verifying correctness of a unit, but specifying it. This implies some kind of test-first approach, where you specify expected behavior. The next level would be to consider the future. What happens when you're done writing this code? Could someone else still understand what's going on? Do you only have technical specifications, or also domain-level specifications?

For unit tests, the danger is that you'll be doing only technical verifications. You may be testing methods, arguments and return values instead of higher-level behaviors. It happens when you're just repeating the logic of the class inside its unit test. You find yourself looking into the box (white box testing), instead of treating the box as an object with proper boundaries.

The best thing you can do is to think hard about

Truncated by Planet PHP, read more at the original (another 5202 bytes)

Categories: Web Technologies

Dark theme in a day

CSS-Tricks - Mon, 05/21/2018 - 13:51

Marcin Wichary has written a great piece that dives into how he used CSS Variables to create a night mode and high contrast theme in an app. There’s so many neat tricks about how to use CSS Variables (Chris has also looked at theming) as well as how to organize them (Andras Galante has an interesting take on this) in here. Plus, Marcin shares some tricks about using filters to invert the color of an image.

I also also love this part of the article where Marcin writes:

I was kind of amazed that all of this could happen via CSS and CSS alone: the colours, the transitions, the vectors, and even the images...

CSS is mighty powerful these days, and it’s posts like Marcin’s that remind me it wasn’t that long ago that theming an app like this would’ve been impossible.

Direct Link to ArticlePermalink

The post Dark theme in a day appeared first on CSS-Tricks.

Categories: Web Technologies

Webinar Wed, 5/23: Troubleshooting MySQL Concurrency Issues with Load Testing Tools

Planet MySQL - Mon, 05/21/2018 - 11:41

Please join Percona’s Principal Support Escalation Specialist, Sveta Smirnova, as she presents Troubleshooting MySQL Concurrency Issues with Load Testing Tools on Wednesday, May 23, 2018 at 11:00 AM PDT (UTC-7) / 2:00 PM EDT (UTC-4).

Register Now


Normally, we use benchmarking tools when we are developing applications. When applications are deployed, benchmarks tests are usually too late to help.

This webinar doesn’t cover actual benchmarks, but it does look at how you can use benchmarking tools for troubleshooting. When you need to repeat a situation caused by concurrent client execution, they can be your best option. These types of issues include all kinds of locking and performance issues, along with stalls and crashes.

In this webinar Sveta will cover some of the main tools she uses, such as (but not limited to) SysBench and mysqlslap. She will show how to use the tools’ standard options while working with specific custom problems, and how to script them to develop test cases that are as close to real life scenarios as possible.

Register for the webinar.

Sveta Smirnova, Principal Support Escalation Specialist

Sveta joined Percona in 2015. Her main professional interests are problem-solving, working with tricky issues, bugs, finding patterns that can quickly solve typical issues and teaching others how to deal with MySQL issues, bugs and gotchas effectively. Before joining Percona, Sveta worked as Support Engineer in MySQL Bugs Analysis Support Group in MySQL AB-Sun-Oracle. She is the author of book “MySQL Troubleshooting” and JSON UDF functions for MySQL.

The post Webinar Wed, 5/23: Troubleshooting MySQL Concurrency Issues with Load Testing Tools appeared first on Percona Database Performance Blog.

Categories: Web Technologies