Mar30Speeding up Mootools with createDocumentFragment()

A couple of days ago David Walsh posted a blog entry where he recommended a video from Google about JavaScript. I’ve found this very interesting and I have done some research about how to implement this very easy to Mootools. There are a lot of do’s and dont’s but what is the best practice for us as a Mootools developer? How to avoid the basic Mootools solutions and speed up your plugins? Well, I’ll post my neat workarounds to get your speed up.

I’ll start with modifying the DOM by injecting elements with the Mootools function inject(). Injecting elements to the DOM is very common with Mootools but it will make it slow down. To speed up you’ll have to do as little DOM modification as possible.

For example you load a JSON file and add elements depending on the content of the request. In this example we don’t avoid the Mootools each() function. We focus on the point that we don’t call the inject() function every time. This is my solution.Add the following lines to you general JavaScript file to implement a new function. I’ll recommend this if you

view plaincopy to clipboardprint?
window.addEvent('domready', function() {
Element.implement({
docFragment: function(){
return document.createDocumentFragment();
}
});
});
We’re going to add options to a select element, based on the JSON request.

view plaincopy to clipboardprint?
var fragment = Element.docFragment();

json.each(function(o){
var option = new Element('option',{'value': o.value, 'html': o.html});
fragment.appendChild(option); //No reflow
});

$('select').appendChild(fragment); //Reflow!
Results
I’ve done some testing and I think it helped me pretty good to speed up my scripts. I’ve modified my cvLinkSelect class and did some testing with it. Here are the results. Not very impressive at this point but you can see it will help the performance.



The test handles a 12 lined JSON request and for each record an option element will be added to the DOM. Not a very big effort for a browser, but you’ll see that there is some difference on the most common browsers and it’s no surprise that IE is the slowest of them all. If you scale this up it has to be a large difference and I’m confident with that.

Read more about createDocumentFragment on Mozilla Developer Center.

reference : http://youngdutchdesign.com/speeding-up-mootools-with-createdocumentfragment

Flipping Out

Flickr is somewhat unique in that it uses a code repository with no branches; everything is checked into head, and head is pushed to production several times a day. This works well for bug fixes that we want to go out immediately, but presents a problem when we’re working on a new feature that takes several months to complete. How do we solve that problem? With flags and flippers!

Feature Flags


Flags allow us to restrict features to certain environments, while still using the same code base on all servers. In our code, we’ll write something like this:

if ($cfg.enable_unicorn_polo) {
// do something new and amazing here.
}
else {
// do the current boring stuff.
}
We can then set the value of $cfg.enable_unicorn_polo on each environment (false for production, true for dev, etc.). This has the additional benefit of making new feature launches extremely easy: Instead of having to copy a bunch of new code over to the production servers, we simply change a single false to true, which enables the code that has already been on the servers for months.

Feature Flippers


Flags allows us to enable features on a per environment basis, but what if we wanted to be more granular and enable features on a per user basis? For that we use feature flippers. These allow us to turn on features that we are actively developing without being affected by the changes other developers are making. It also lets us turn individual features on and off for testing.

Here is what the Feature Flip page looks like:



Continuously Integrating
Feature flags and flippers mean we don’t have to do merges, and that all code (no matter how far it is from being released) is integrated as soon as it is committed. Deploys become smaller and more frequent; this leads to bugs that are easier to fix, since we can catch them earlier and the amount of changed code is minimized.

This style of development isn’t all rainbows and sunshine. We have to restrict it to the development team because occasionally things go horribly wrong; it’s easy to imagine code that’s in development going awry and corrupting all your data. Also, after launching a feature, we have to go back in the code base and remove the old version (maintaining separate versions of all features on Flickr would be a nightmare). But overall, we find it helps us develop new features faster and with fewer bugs.

reference : http://code.flickr.com/blog/2009/12/02/flipping-out/

Quantum of Deployment

Deployinator is now Open Source!
Grab it on github: https://github.com/etsy/deployinator

We deploy a lot of code. Deployinator is our creation to make that as easy and painless as possible. Deployinator is a one button web-based deployment app. Hit that button and code goes to our webservers and is serving requests in almost no time. Using Deployinator we’ve brought a typical web push from 3 developers, 1 operations engineer, everyone else on standby and over an hour (when things went smoothly) down to 1 person and under 2 minutes.

At Etsy, we’re doing what’s come to be called Continuous Deployment. However, what we’ve learned is that having a tool like Deployinator is useful for more than just enabling that. This post is about those benefits – for anyone deploying web code.

Why

Our job as engineers (and ops, dev-ops, QA, support, everyone in the company actually) is to enable the business goals. We strongly feel that in order to do that you must have the ability to deploy code quickly and safely. Even if the business goals are to deploy strongly QA’d code once a month at 3am (it’s not for us, we push all the time), having a reliable and easy deployment should be non-negotiable.

It’s a metric I’ve come to call the “quantum of deployment”: what’s the smallest number of steps, with the smallest number of people and the smallest amount of ceremony required to get new code running on your servers? This isn’t a trivial question. Even if you’re on a slow release cycle, and have a push engineer, what happens if there’s an emergency push needed? Does it go through your normal process, or is there a fast-lane? Do your fast-lane deployments get logged? Are they measured for speed? Is everyone aware that it happened the way they would for a normal deployment, or is it your dirty little secret?

It’s not hard to get started. If you currently have a bunch of shell scripts that move everything in place, wrap those up with a single shell script. The most important thing is that it’s ONE easy step. This might require changing your process. Try to remove or replace special cases. The less thought it takes to deploy, the more you can focus on getting stuff done.

Once deploying is No Big Deal, a lot of things can change. Features can go out a piece at a time instead of one all-or-nothing push. Your app configuration options can be in code – and changed quickly. Your hair can grow back. Puppies will lick your face!

What

Custom software? There’s a lot of choice out there, and we generally try to not reinvent the wheel whenever possible (and this wheel has been invented again and again). After comparing our requirements with the available software, we decided to roll our own. Here’s what we were looking for:

Web based
Logged (When, What and Who)
Adaptable to our network
Run from a central location
Announced in our IRC and email
Transparent in regards to its actions
Integrated with our graphing/monitoring tools
A lot of our requirements are inspired by the way Flickr deploys, as documented in Building Scalable Websites (Written by Friend of Etsy, Cal Henderson).

For anyone deploying code (engineers, designers… anyone really), it’s an easy process. Once your code is ready to go, you go to Deployinator and push the button to get it on QA. From there it visits Princess (see the sidebar). Then, when it’s ready to go live, you hit the “Prod” button and soon your code is live, and everyone in IRC knows who pushed what code, complete with a link to the diff. For anyone not on IRC, there’s the email that everyone gets with the same information.

What it looks like
This is the main Deployinator screen. Here is how we deploy the “web stack”.



Sidebar: What the heck is a “Princess”?

Princess is our staging environment. So why didn’t we just call it “staging”? Partly, that’s just how we roll. We used to have an environment called “Staging” that was the last stop before code went live to everyone. However, it was not ideally set up; the first time your code would interact with actual production hardware was when you deployed. Princess uses production data stores, our production network and production hardware. In order to make a clean mental break from the old way, one of our rad engineers, Eric Fixler, came up with “Princess”.

Here’s our IRC bot telling everyone that something went out. It also includes a link to the commits that went live.



How

When we first brought Deployinator online, it was just a web frontend to the shell scripts that moved everything in the right place. What we gained by putting a screen in front of it was the ability to iterate the backend without changing the experience for people deploying. Deployinator currently uses svn to update the code, then rsync to move it between environments.

Another important part of Deployinator is that the environments are a one way street. Code going from Princess to production is unaffected by any commits that have happened since getting on princess. This creates something of a “mantrap“, so that we know exactly what we’re deploying. No surprises!

Deployinator isn’t used just for our web stack either. With the simple architecture we’ve built, we can add all kinds of stuff to it easily. It’s currently used for many different things such as the API, Lists service, internal admin-only tools and others. Having a single deployment process has removed a lot of complexity.

When

This isn’t a post about continuous deployment. Having a very simple deployment procedure is something you should do even if the thought of deploying your code 20 times a day scares you. Deployment can be a contentious subject with many stakeholders. Getting it simple and repeatable allows everyone to share a common vocabulary.

For the nerds…

Transporting the bits and bytes
Here’s a rundown of some of the interesting parts of how Deployinator actually moves bits around. As mentioned above, this has changed and will change again. We analyze our entire process and have some low-hanging performance fruit to pick. As of today, an API push takes about 18 seconds, a Princess push takes about the same, and a production web push is 70-150 seconds. Here are the steps that a web push goes through:

From the repo of truth

We’re deploying directly from trunk (that’s a whole other post!). So the first step of deploying is to update the code on the deploy host.

Builda what now?

After the code is updated, we run “builda”, an app we wrote to take our assets and bundle them up with lots of magic. We use a combination of javascript async loading, Google’s closure and versioned directories to make things like css, javascript and sprites as fast as possible.

Rsync

At this point, we have a bunch of directories on our deploy host that represent our web tree. We then rsync to a staging area on each web box.

Fanout

At some number of boxes, rsyncing back to a single push host stops working. We’re employing a strategy called fan out. We rsync in chunks of 10 hosts at a time. This is one area where a lot of speed ups will be happening soon.

First they came for our assets…

Pop quiz, hotshot: Someone visits the site during a deployment and box 1 (the one they randomly get) has the new code. The html they’re returned refers to a new image. When they request that image, they end up on box 451.. which doesn’t have that asset yet. What do you do? WHAT DO YOU DO?

We’ve solved this with two steps. The first (mentioned above) is versioned asset directories. The next is to get those assets on ALL hosts before ANY host has the new code referring to it.

Graceful

We’re using APC user caching, and expect it to have fresh data each deployment. Things like some application settings, database fields and routes are all cached for super fast lookups. However, if someone changes something in some code going out, we need to make sure that it’s fresh. We’re currently issuing a graceful restart to our apaches on each deployment.

Deployinator itself
One of the design goals of Deployinator has been to be as simple as possible. It’s a sinatra web app, but could really be written in anything. The script that does the svn updating (and checking out for new stacks) is in PHP and some of the straight-up simplest code possible.

The commands that Deployinator runs through for each different stack are listed in ruby methods, and are mostly strings (with servers and such interpolated). It’s easy for anyone to come in and change how something works. Simple, understandable software that gets the job done.

The one fancy bit of Deployinator is the streaming rack middleware that powers the live updating code window:



Database DDLs aren’t code
An awesome feature of Capistrano is the ability to run schema migrations as part of your deployment. At a certain scale, however, database changes become more time consuming and dangerous. All of our schema changes go through a stringent process with several checks in place. However, not all schema is defined in the database. Whenever we have schema that’s defined in code, or inside the data itself, it’s just a normal code push.

Conclusion

Our deployment process is a very important part of how we work at Etsy. We treat it just like our web code, databases or other “serious” things. Deployinator has helped us to get more features out faster with less defects and drama. As we triple our engineering team in 2010 (we’re hiring!), tools like this are what make it possible for us to change the world.

reference : http://codeascraft.etsy.com/2010/05/20/quantum-of-deployment/

Mysql忘記root密碼

1.先停掉mysql

# /etc/init.d/mysql stop

2.以–skip-grant-table& 的參數啟動mysql
/usr/bin/mysqld_safe --skip-grant-table&

3. 更改root 密碼

# mysql mysql
mysql> UPDATE user SET password=password('123456') WHERE user='root';
mysql> exit

4.停掉mysql再重跑

# /etc/init.d/mysql stop
# mysql -u root -p

reference : http://tw.myblog.yahoo.com/cherry-liang/article?mid=579&prev=633&next=-2&page=1&sc=1

You could use the DOMDocument class to reformat your xml


$dom = new DOMDocument('1.0');
$dom->preserveWhiteSpace = false;
$dom->formatOutput = true;
$dom->loadXML($simpleXml->asXML());
echo $dom->saveXML();