You can copy and paste the text anywhere.
No internet connection required.
It's even more compatible than emoji's.
Pay attention to charges if texting and have fun!
Saturday, April 13, 2013
Zalgo text iphone app
Troll your friends with text like Z̬̗̙̜̭̺͍̥̯̅̿A̘͙͔̜̥̿͑̄̍L̪̼̘͈͈̫̫͕͖ͭ̋ͣG̦̝͇̺̻̩̙ͣ̒͒̀͌̓̚Ọ̘̠̋́̈!
You can copy and paste the text anywhere.
No internet connection required.
It's even more compatible than emoji's.
Pay attention to charges if texting and have fun!
You can copy and paste the text anywhere.
No internet connection required.
It's even more compatible than emoji's.
Pay attention to charges if texting and have fun!
Thursday, April 11, 2013
BTC Guild mate
BTC Guild mate offers an overview of your bitcoin miners and expected earnings through the BTC Guild (BTCGuild.com) bitcoin mining pool.
Earnings are estimations based on the latest currency exchange and your current miners' speed.
Currency exchange is provided via coinmill.com
Proper ipad version and more goodies coming soon.
Earnings are estimations based on the latest currency exchange and your current miners' speed.
Currency exchange is provided via coinmill.com
Proper ipad version and more goodies coming soon.
Saturday, February 25, 2012
Refactoring your wordpress theme with Skellie
Skellie allows for maintainable, readable, reusable code within wordpress themes without breaking wordpress or plugins. It gives you a simple but powerful toolbox with structured partials, layouts and templates.
TL;DR
If you want to see what other problems Skellie solves view my presentation about it
Installation
Refactoring a single template
Let's refactor the home page.
Remove get_header() and get_footer() from your template and choose a layout at the top within comments like this:
Refactoring the template into a layout and basic partials
Step 1 - Merge into a working layout
By convention wordpress themes split wrapping code into header.php and footer.php and then call get_header(), get_footer() within the template.
Create layouts/myOwnLayout.php and copy the contents of your header.php.
Add
Your homepage template is now powered by Skellie, is pretty much an unreadable mess, but should work as before and you can begin cleaning it up.
Step 2 - Split into default partials
Now you can start cleaning up the mess.
Let's bring it up a notch.
Step 3 - Split your layout in organized partials
Now the layout should be clean but your template is still full of code.
You can use partials however you want to lighten it up.
My conventions are :
Chance is you would end up creating partials for a certain slug that do not differ that much between types.
Use the 3rd parameter of partial() to pass arguments to your partial:
Whatever parameters are passed through the associative array are accessible through the partial as public variables of $this. (If a param is not set it always returns null)
For example within partials/list/category.php you could do:
Conclusion
That's it.
Feel free to fork it or submit issues that arise on github.
TL;DR
If you want to see what other problems Skellie solves view my presentation about it
Installation
- Download Skellie
- Copy the directories: layouts, library and partials into your theme's main dir.
- Add the following in your functions.php :
Refactoring a single template
Let's refactor the home page.
Remove get_header() and get_footer() from your template and choose a layout at the top within comments like this:
/**Enabling the cherry picking requirement during installation allows Skellie to take over rendering but only for templates that explicitely ask for a layout. All your remaining templates will continue using wordpress.
* @layout myOwnLayout
*/
Refactoring the template into a layout and basic partials
Step 1 - Merge into a working layout
By convention wordpress themes split wrapping code into header.php and footer.php and then call get_header(), get_footer() within the template.
Create layouts/myOwnLayout.php and copy the contents of your header.php.
Add
<?php echo $this->content(); ?>then finish up with the contents of footer.php.
Your homepage template is now powered by Skellie, is pretty much an unreadable mess, but should work as before and you can begin cleaning it up.
Step 2 - Split into default partials
Now you can start cleaning up the mess.
- Move your starting html-tag and <head>.*</head> into partials/header.php and replace the code in the layout with
<?php echo $this->partial('header'); ?>
- Leave the starting body-tag intact or replace it with
<body <?php body_class('layout-'.$this->layout); ?>>
That will give the body-tag classes of both the layout and the template, so you can minimize the need of creating more layouts. - Move your common html code that lies right before the ending body-tag [including wp_foot()] into partials/footer.php. Mine contains just a wp_foot call and a chrome-frame snippet.
- Replace that code with
<?php echo $this->partial('footer'); ?>
Let's bring it up a notch.
Step 3 - Split your layout in organized partials
- Replace all get_template_part($slug, $name) calls with:
<?php echo $this->partial($slug, $name); ?>
Copy the contents of {$slug}-{$name}.php into partials/$slug/$name.php
The idea is to eventually delete all partials from the main theme dir when templates no longer need them. - Create a directory partials/navigation
- Move every navigation menu code into it's own file in partials/navigation/{$name}.php and replace the code in the layout with:
<?php echo $this->partial('navigation', $name); ?>
- Move remaining wordpress (e.g. a search form or sidebars) or plugin code (e.g. breadcrumbs) to its own file and replace it with partial() calls.
If you do not use subtypes for a certain partial you can store the code in partials/{$slug}.php and there is no need to create a directory for it.
Now the layout should be clean but your template is still full of code.
You can use partials however you want to lighten it up.
My conventions are :
But first the fun part.
- partials/list/$type.php for aggregating posts of a type (cat, post_type etc)
- partials/preview/$type.php for showing an excerpt of a single post
- partials/content/$type.php for showing the full content of a single post
- partials/pagination/$type.php for things like next/previous article, wp_paginate or link to a list of articles
Chance is you would end up creating partials for a certain slug that do not differ that much between types.
Use the 3rd parameter of partial() to pass arguments to your partial:
Whatever parameters are passed through the associative array are accessible through the partial as public variables of $this. (If a param is not set it always returns null)
For example within partials/list/category.php you could do:
Conclusion
That's it.
Feel free to fork it or submit issues that arise on github.
Wednesday, February 15, 2012
Skellie after a sprint
The last 2 weeks I got to use Skellie in action, in order to build a new wordpress project from scratch.
The results are encouraging.
The code seems cleaner and readable and partials are easily reusable.
The main layout file is just so clear:
During development I came accross two dark corners of wordpress, namely the search and comment forms.
Search form
By default wordpress prints the same id in the search form which ends up in invalid html if you need 2 instances of it (e.g. repeating the search form within the search results page). The solution was to ignore the search form and come up with a new partial in partials/search-form.php
Comment form
The comment form was less of a hassle. Hiding the tips and title was enough to get going.
Using 2 partials to loop through the comments and print them finishes up the story.
Future development:
Some things that could be changed also became apparent during the building process.
I was thinking about the possibility of having the partial methods return the render result as a string instead of directly printing it like wordpress used to.
It makes sense. It allows for more flexibility and adjustment of output. You can cache it, alter it (if you have to), decorate it or just print it.
Also with the 5.4 short tag re-entering the game the overhead of manually printing will be minimal.
Get_template_part of wordpress used to directly print but get_template_part sucked anyway.
Saturday, February 4, 2012
Introducing Skellie, a real wordpress theme skeleton
So lately at work I've been stuck doing custom wordpress projects to keep the money flow steady while others do the cool stuff -.-
Problem #1:
Everytime a new project started we picked a new "empty" base theme.
It was supposed to be the basis for building our own. But almost no project looked the same.
We always had to go in and change everything in the templates.
Sometimes html5 was not allowed, sometimes the structure had to be totally different and functionality was not needed.
Sometimes it was grid960, sometimes boilerplate with again our implementation changing like using scss or not.
So have fun cleaning and recoding all the stupid wordpress templates that your theme came along with.
We ended up using almost nothing from the initial template but were stuck with 100 functions within functions.php to which we had to add 10 more.
Problem #2
So I started from scratch until I reached a point contemplating about get_template_part.
If you don't know what that is (lucky you), it's basically including a different file with a fallback to a default file:.
So you can get_template_part('loop', get_post_type()) and if there's a loop-$postType.php file found it will be loaded.
Otherwise loop.php is loaded.
No other configuration can happen. Also all those template parts have to reside in your base theme directory.
My last project had around 45 template parts...
There had to be a better way of doing this.
Thoughts on Problem #1
I couldn't care less about theme inheritance.
There's no point if your theme has no functionality you really need.
So the best theme for me would be a theme with nothing in functions.php (or at most just a few commented out lines code so I don't have to lookup things like how to add custom thumbnail sizes).
I would not want my theme to decide what kind of css framework I'm going to use and would not like 100 stupid functions printing html that I would have to edit or never use.
Thoughts on Problem #2
I would love to at least be able to configure my template parts. Pass some parameters in cleanly so I can skip putting logic in them or splitting them into more template parts.
Also I would love the ability to group and structure them differently. I want my preview templates (that do not show the full content) in a preview folder. Template parts are not templates.
In combination with the above, how cool would it be if I could pass the excerpt length as a parameter to the template part and then maybe with more parametrization I wouldn't need more than 1-2 template parts.
Enter Skellie
Skellie is a real skeleton of a theme and attempts to solve the aforementioned problems:
Solution to Problem #1
Layouts and Templates
Skellie provides partials and layouts and redesigns the way templates work.
The template is still the main part of the application.
A layout is the wrapper around your page content. Calling the header, footer and sidebars amongst other common things should be in the layout.
You can have several layouts like 3-columns, 2-columns-1-sidebar along with your default but you shouldn't need that many. All of them will be in the same directory (layouts/) in any case.
You can still select a template for your pages as usual. However your template can now select its layout using with a special comment (or assume default.php).
The template should now only contain the main content of the page and call upon partials to help it render stuff.
Partials
Partials are like views, getting rid of get_template_part. From within a layout, template or even another partial you can use
echo $this->partial('<slug>', '<type>', $args)
and it will looks for the first partial it finds located in the following paths:
E.g. if $args is array('someVar' => 'someValue') then $this->someVar will be 'someValue' within the partial.
Notes:
PHP 5.3 is required.
I am aware that using Closures with including files is weird.
If something feels still extra it will be removed.
The code is experimental and everything can change.
Feedback is appreciated.
Problem #1:
Everytime a new project started we picked a new "empty" base theme.
It was supposed to be the basis for building our own. But almost no project looked the same.
We always had to go in and change everything in the templates.
Sometimes html5 was not allowed, sometimes the structure had to be totally different and functionality was not needed.
Sometimes it was grid960, sometimes boilerplate with again our implementation changing like using scss or not.
So have fun cleaning and recoding all the stupid wordpress templates that your theme came along with.
We ended up using almost nothing from the initial template but were stuck with 100 functions within functions.php to which we had to add 10 more.
Problem #2
So I started from scratch until I reached a point contemplating about get_template_part.
If you don't know what that is (lucky you), it's basically including a different file with a fallback to a default file:.
So you can get_template_part('loop', get_post_type()) and if there's a loop-$postType.php file found it will be loaded.
Otherwise loop.php is loaded.
No other configuration can happen. Also all those template parts have to reside in your base theme directory.
My last project had around 45 template parts...
There had to be a better way of doing this.
Thoughts on Problem #1
I couldn't care less about theme inheritance.
There's no point if your theme has no functionality you really need.
So the best theme for me would be a theme with nothing in functions.php (or at most just a few commented out lines code so I don't have to lookup things like how to add custom thumbnail sizes).
I would not want my theme to decide what kind of css framework I'm going to use and would not like 100 stupid functions printing html that I would have to edit or never use.
Thoughts on Problem #2
I would love to at least be able to configure my template parts. Pass some parameters in cleanly so I can skip putting logic in them or splitting them into more template parts.
Also I would love the ability to group and structure them differently. I want my preview templates (that do not show the full content) in a preview folder. Template parts are not templates.
In combination with the above, how cool would it be if I could pass the excerpt length as a parameter to the template part and then maybe with more parametrization I wouldn't need more than 1-2 template parts.
Enter Skellie
Skellie is a real skeleton of a theme and attempts to solve the aforementioned problems:
Solution to Problem #1
- Your functions.php will be empty apart from a function allowing Skellie to provide the view architecture and take over from wordpress.
- Your layout will be minimal.
- Your default partials will be non-existent apart from examples and so you can test how it works.
- There are no stylesheets or javascript. Modernizr and normalise.css are in place if you want them but not enabled.
- The header is html5 but together with the footer it's just 20 lines so feel free to remove it.
Layouts and Templates
Skellie provides partials and layouts and redesigns the way templates work.
The template is still the main part of the application.
A layout is the wrapper around your page content. Calling the header, footer and sidebars amongst other common things should be in the layout.
You can have several layouts like 3-columns, 2-columns-1-sidebar along with your default but you shouldn't need that many. All of them will be in the same directory (layouts/) in any case.
You can still select a template for your pages as usual. However your template can now select its layout using with a special comment (or assume default.php).
The template should now only contain the main content of the page and call upon partials to help it render stuff.
Partials
Partials are like views, getting rid of get_template_part. From within a layout, template or even another partial you can use
echo $this->partial('<slug>', '<type>', $args)
and it will looks for the first partial it finds located in the following paths:
- partials/<slug>/<type>.php
- partials/<slug>.php
- partials/<slug>/default.php
E.g. if $args is array('someVar' => 'someValue') then $this->someVar will be 'someValue' within the partial.
Notes:
PHP 5.3 is required.
I am aware that using Closures with including files is weird.
If something feels still extra it will be removed.
The code is experimental and everything can change.
Feedback is appreciated.
Saturday, September 10, 2011
How to force babelfish firefox plugin compatibility [for Mac]
So because of the stupid rapid release schedule of Mozilla many addons seem to break after a firefox update.
However we are thankful for the addons being open source and simply xml/javascript code which we can hack around.
I'll describe this for Mac Users.
Basically every addon ships with two parameters which is the minimum and maximum firefox version required in order for it to work. That variable is not detected automagically and is just selected by the developer of the plugin. For Babelfish 1.9.6 the maximum version is set to 5.*
Changing this to the latest will suffice.
So first step is to find the Firefox Extensions Directory:
In this case the babelfish plugin is a directory. If you see many directories open them one by one and right-click their chrome.manifest file within. On the menu go to Open With and select Text Edit or another editor. In the correct directory of babelfish the manifest file will start with the words: "content babelmousish".
Ok so now you've found the plugin directory. Within that same directory you'll also find a file called install.rdf
That file is xml encoded which is also plaintext. So again right click open with a text editor and go to line 12.
In that line change 5.* to the latest.
Save the file and restart firefox. Babelfish should now be compatible with the latest version of firefox.
Just for the record if the plugin was to be an xpi file we would unzip it with a compression program, change the rdf file, store it, zip it again and rename it back to xpi replacing the older one.
However we are thankful for the addons being open source and simply xml/javascript code which we can hack around.
I'll describe this for Mac Users.
Basically every addon ships with two parameters which is the minimum and maximum firefox version required in order for it to work. That variable is not detected automagically and is just selected by the developer of the plugin. For Babelfish 1.9.6 the maximum version is set to 5.*
Changing this to the latest will suffice.
So first step is to find the Firefox Extensions Directory:
- If you don't see a library folder within your home directory :
Open up a terminal and run : chflags nohidden ~/Library
That will unhide the Library folder (at least for Lion it is needed)
- So now go to your home directory and open the Library folder.
- Find the Application Support folder within.
- Find the firefox folder within (not the mozilla one!)
- Open the Profiles folder within the firefox folder and somehow find your own profile-directory and open it (hopefully there's only one)
- Behold the directory called extensions.
In this case the babelfish plugin is a directory. If you see many directories open them one by one and right-click their chrome.manifest file within. On the menu go to Open With and select Text Edit or another editor. In the correct directory of babelfish the manifest file will start with the words: "content babelmousish".
Ok so now you've found the plugin directory. Within that same directory you'll also find a file called install.rdf
That file is xml encoded which is also plaintext. So again right click open with a text editor and go to line 12.
In that line change 5.* to the latest.
Save the file and restart firefox. Babelfish should now be compatible with the latest version of firefox.
Just for the record if the plugin was to be an xpi file we would unzip it with a compression program, change the rdf file, store it, zip it again and rename it back to xpi replacing the older one.
Subscribe to:
Posts (Atom)