Getting all custom window children.

January 12th, 2017 | Permalink

On some websites their creators store some useful functions in window scope directly. For example, when site is all AJAX-driven et cetera, like vk.com, it may be useful from both solidity and performance perspectives, I believe. Of course, they say that “littering” global ojbect is bad, but it is bad only when you’re developing a library or do not exactly do what are you doing.

Now, as in previous post, by creating the IFrame and accessing its’ contentWindow we can get a “fresh” window object. It is useful when we want to restore some redefined native
code, but also we can also get all custom children of current window object. Getting all new variables in window, grouped by their type:

(function(ifr){
    document.body.appendChild(ifr);      
    var newKeys = {};

    Object.keys(window).forEach(function(key){
        if(typeof ifr.contentWindow[key] == 'undefined'){
            var type = typeof window[key];
            newKeys[type] = newKeys[type] || {};
            newKeys[type][key]=window[key];
        }
    });
    ifr.parentNode.removeChild(ifr);
    return newKeys;
})(document.createElement('iframe'));

This comes in handy sometimes. For example, when you’re writing a userscript for some website. Or just want to dig in someone else’s code which is interesting sometimes on complicated websites (as chrome developer console, for example, allows you to right-click the function and “Show function definition”, even allowing pretty-printing minified scripts)

Restore console functions in JS

December 28th, 2016 | Permalink

Naughty boys and girls sometimes replace browser’s console object from window object to eliminate debug messages from scripts (instead of just redefining it inside closure). There IS a way to restore it. I do it like this:

(function(ifr){
  document.body.appendChild(ifr);
  window.console = ifr.contentWindow.console;
  ifr.parentNode.removeChild(ifr);
})(document.createElement('iframe'));

‘course, this should be done after the DOM is ready, I guess. Most cases I use it I’m fiddling in browser’s console and have no access to page source anyway.

Also I was lazy to hard-code the latin alphabet and did this:

Array.apply(0,Array(26)).map(function(a,i){return String.fromCharCode(i+97);});
// ["a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z"]

And yea, I was bored.

MEMO: Configuring LAMP stack with MariaDB on OVH’s VPS under Ubuntu 16.04

December 3rd, 2016 | Permalink

A tiny article on configuring LAMP stack using MariaDB and Phpmyadmin under Ubuntu 16.04. This article is basically a memo. I wrote it mostly for myself as I often am doing all of these and always have to be sure I didn’t forget anything in the process.

Read on

mdhabr – a commandline tool to convert markdown to habrahabr markup

November 21st, 2015 | Permalink

I have written a small toy to prepare articles for habrahabr using markdown.

I guess it will be buggy like hell since it is the first version, yet still…

To use it it you have to have NodeJS and installed as well as PATH variable set correctly (node installer does this all for you, just in case)

npm install -g markdown-habr

And it should be available now in your system. You should be able to just do something like

mdhabr my_article.md

Mongoose – a tiny, one-file http server. Absolute love.

July 29th, 2015 | Permalink

The story is this: I needed a tiny web server to provide with some front-end only website. The website used json loaded via AJAX calls, so was intended to be running on a server. One could not just open the index.html file in your browser.

But I needed the end user to be able to run my website anyway. Since I was pretty sure they will be running it on Windows I needed something like this:

  • It should be a single executable file. To not litter the project directory with tons of files
  • It should be portable. No installation. No complex, env-dependent configuration.
  • It should support command prompt
  • I should be able to specify the root (document) folder which files will be served. I didn’t need any CGI. Just files seved over HTTP correctly.
  • All of the files should be served with correct headers
  • I had not security concern since it was intended for local use only.

Now right, I know one can run server via node, ruby and even php. But again that was not an option, as well as assembling some portable nginx/apache etc.

After several unsuccessful tries I found Mongoose. It’s free (well it’s non-CGI edition is) and it gave me all I wanted and even more – the ability to run the browser on start. And it is pretty easily configurable via command line parameters. It even supports some rewrites!

..and then I gave the end user a bat file to run it:

taskkill -im mongoose.exe
start "Mongoose" "%~dp0\server\mongoose.exe" -listening_port 8085 -document_root "%~dp0\www"

And now sometimes I still use it as a way to quickly test my front-end stuff.