Over the weekend I was experimenting with a setup of MySQL connections in the Node/Express web app that I’m working on. It led me to create this super simple middleware module express-myconnection that provides a consistent API for MySQL connections during the request/response life cycle. It supports three different strategies of managing db connections:
single for a singleton connection on an app instance level,
pool based connections, and a new connection per each
request. It’s also capable of auto releasing/closing connections if configured with either the
The conclusion of my experiments is that for now I will stick with a
single. I believe this should work just fine when you think about the single-threaded nature of node. If I experience any issues switching to
pool based or connections per
request will be matter of setting single flag in my app configuration.
Below you can find some more info about the different strategies and how you can use them in your own projects.
single – creates a single database connection for the whole application instance. The connection is never closed. In case of a disconnection, it will try to reconnect again as described in the node-mysql docs.
pool – creates pool of connections on an app instance level, and serves a single connection from the pool per request. The connection is auto released to the pool at the response end.
request – creates new connection per each request, and automatically closes it at the response end.
Configuration is straightforward and you use it as any other middleware. The first param it accepts is a node-mysql module, second is a db options hash passed to the node-mysql module when the connection or pool is created. The third is a string defining the strategy type.
express-myconnection extends request object with the
getConection(callback) function this way the connection instance can be accessed anywhere in routers during the request/response life cycle:
In this very short video tutorial you will learn how to change language of your Creative Cloud applications. This can be very useful especially when your CC apps get installed in your native language but you want to use for example an English version instead 😉
As you may know, recently I’ve been dealing with Chrome Extensions and their APIs quite a bit. This is because I’ve been working on my Responsive Inspector tool. (If you haven’t seen it yet and you are into Responsive Web Designs I recommend you check it out!) Overall I had a great experience with the Chrome Extensions API, except for just one function that really gave me a hard time. This function is
captureVisibleTab, which is a key to whole page screen shots feature that I implemented in Responsive Inspector.
The issue I experienced with it was that on some sites the captured screen shots had double the normal resolution. This was only happening on my MacBook with Retina display, and not on every site. On the sites that had this issue, I started isolating the problem element by element and I discovered that the root cause was a
translate3d transformation. To work around this problem I included a div element with
transform: translate3d(0,0,0) in a page that embeds in an iframe the captured site so that every screen shot had doubled resolution no matter if it used translate3d or not.
Next I called
canvasContext.scale(1/window.devicePixelRatio, 1/window.devicePixelRatio) on the
Canvas Context that I drew captured image into. This scaled screen shot to proper resolution, and the latest version of Responsive Inspector (now available in Chrome Web Store) runs like a charm on Retina MacBooks