Scaling Magento presentation with 60 slides and notes, which was then reviewed by Alan Storm.
package main | |
import ( | |
"crypto/tls" | |
"crypto/x509" | |
"log" | |
"net/rpc" | |
) | |
func main() { |
delimiter ;; | |
drop procedure if exists build_catalog;; | |
create procedure build_catalog(IN categories INT, IN products INT) | |
begin | |
SET @category_count = 1; | |
SET @CATNAMEPREFIX = "Category "; | |
SET @CATURLKEYPREFIX = "cat-"; | |
SET @CATURLPATHPREFIX = "catpath-"; | |
SET @ROOTCATEGORY = 2; | |
SET @INCLUDEINMENU = 1; |
// Just before switching jobs: | |
// Add one of these. | |
// Preferably into the same commit where you do a large merge. | |
// | |
// This started as a tweet with a joke of "C++ pro-tip: #define private public", | |
// and then it quickly escalated into more and more evil suggestions. | |
// I've tried to capture interesting suggestions here. | |
// | |
// Contributors: @r2d2rigo, @joeldevahl, @msinilo, @_Humus_, | |
// @YuriyODonnell, @rygorous, @cmuratori, @mike_acton, @grumpygiant, |
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
-
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the
secure
flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection. -
Use production SSL certificates locally. This is annoying
Attention: the list was moved to
https://github.com/dypsilon/frontend-dev-bookmarks
This page is not maintained anymore, please update your bookmarks.
<?php | |
/** | |
* Drop this into the shell directory in the Magento root and run with -h to see all options. | |
*/ | |
require_once 'abstract.php'; | |
/** | |
* Fix duplicate url keys for categories and products to work with the 1.8 alpha1 CE url key constraints. |
This is just a small post in response to [this tweet][tweet] by Julien Pauli (who by the way is the release manager for PHP 5.5). In the tweet he claims that objects use more memory than arrays in PHP. Even though it can be like that, it's not true in most cases. (Note: This only applies to PHP 5.4 or newer.)
The reason why it's easy to assume that objects are larger than arrays is because objects can be seen as an array of properties and a bit of additional information (like the class it belongs to). And as array + additional info > array
it obviously follows that objects are larger. The thing is that in most cases PHP can optimize the array
part of it away. So how does that work?
The key here is that objects usually have a predefined set of keys, whereas arrays don't:
Locate the section for your github remote in the .git/config
file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = [email protected]:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
to this section. Obviously, change the github url to match your project's URL. It ends up looking like this: