Blog.Andrei.MD

PHP MySQL localhost not finding socket on mac

On my mac, PHP wouldn’t connect to MySQL to “localhost” server. It turns out that when “localhost” is used, MySQL uses sockets instead of TCP/IP connection. Terminal mysql access to localhost was fine, which suggested that there’s nothing wrong with MySQL config. Only after a while did I think to look at php.ini to see if there are any setting there. Yep, my mac uses /tmp/mysql.sock and php.ini was setup to use /dev/mysql/mysql.sock. After changing to /tmp/mysql.sock and restarting apache it now works like it should. 

Hope you find it helpful.

NearlyFreeSpeech.net DDOS effect

I’m using NearlyFreeSpeech.net (NFS) for some web and DNS hosting. It’s pretty cheap and has plenty of controls - just right for the technical person like me.

However, the recent DDOS (Distributed Denial of Service) attack has shown me that their network is not resilient at all. Particularly, I’m concerned with DNS service. Commercial DNS offerings are meant to use geographically distributed servers NOT all on one network.

Couple of weeks ago, there was a network hardware failure at CrazyDomains.com.au. All of their web sites were down, but the DNS kept going. This is the way it’s supposed to be done.

Now, I’ll probably move all the domains to Zerigo.com and take advantage of their API and domain templates. I was thinking of using the DNS service offered by Linode.com when you sign up to one of their VMs. However, I feel I should go with a dedicated DNS hosting provider this time, not some free or cheapish add-on to hosting.

To conclude, I would like to say that there really aren’t many good DNS hosting services available.

Building a dynamic menu in Shopify using Link Lists and a Snippet

Here’s the result of my mega-hackery to create a menu that can be easily maintained by adding and removing new link lists and items in them. I am a technical guy and was doing all of this as a big blob of HTML in a snippet that was included in every layout. Because there are less technical people who need to be able to manage the content, I’ve moved it all into the link lists which are pretty easy to use.

For those in a hurry, the solution is this:

• One top level link list
• One link list for each top level item
• One snippet to iterate over these lists

So if you have 5 top level items all with submenus, you will need 6 link lists. At this stage, this solution doesn’t deal with top level items that have no submenu because we have no need for it.

The main trick here is to capture the name of each top menu item, handleize it and use it to retrieve each submenu.

The end result is running in production at www.paintaccess.com.au

Shopify Tip: Better Logos in Pixel Printer

Here’s a simple tip to make your Shopify invoices from Pixel Printer looking a bit more professional. If you use a logo, you know that it prints out all blocky. To add a bit more detail and a crisper look you should use a bigger image and scale it down in HTML.

As a guide, you should use an image about 3-4 times bigger. Screen graphics (PNG and JPEG) are roughly 72dpi (dots per inch). For crisp printing you need 300 and up. Some scaling is required.

Example:

If the logo you currently use is 200px wide and 100px tall, you should get a bigger version of this logo. Try 800 x 400px. The rule is simple: multiply each dimension by the same amount, in this case, 200x4 = 800 and 100x4 = 400. This guarantees that the logo has the same proportions. I think it’s better to use an integer scaling factor to help browsers out a bit, otherwise it might look worse on screen. Upload this new logo in shopify into the files area. In Pixel Printer, restrict the image in HTML to the original size like so:

<img href=”MY-800x400-LOGO.PNG” width=”200” height=”100” />

Replace “MY-800x400-LOGO.PNG” with the URL Shopify gives you after you upload the file. Note, if you don’t specify the width and height, you will get a huge image on your invoice, which is not what you want.

When you look at the logo on your screen it may look worse than it did before. This is not a problem because we use PixelPrinter for printing invoices, not looking at them on screen.

Try printing and you’ll see that your logo now has all the crispy details you expect. If this tip doesn’t work for you, try using Firefox.

Use SoX to convert audio formats in mac terminal

Use SoX (http://sox.sourceforge.net/) to convert Audio in terminal.

I found myself working with audio files that came in different formats. I needed them in OGG. Audacity (http://audacity.sourceforge.net/), the super-powerful free audio editor does a good job, but in this case I was looking for a solution using the terminal (command line). After a bit of Googling I came across SoX. It allows me to do easy conversions like so:

$ sox file.wav file.ogg

There are tons of options if you need the tweak the parameters. I didn’t need that for my task, so I didn’t go into details.

Basically, SoX to Audio is what ImageMagick (http://www.imagemagick.org/) is to Images.

To install using ports, just do:

$ sudo port install sox

I want PayPal automation

I want PayPal to provide the world with an API to administer the account and perform operations on it. The only API features available are for processing payments from users.

The available APIs are not enough. I need to be able to work with the account using the API. When running a business on PayPal, you want to move the money quickly. You don’t want your thousands sitting in the PayPal account. I need to automate the account. I want the money to move automatically. If I had an API, I would be able to query the account balance daily and then trigger a withdrawal to a bank account if the amount is above some value.

Maybe API is not necessary, maybe PayPal could add this functionality into the system themselves. Something tells me that they are a bit reluctant to add this kind of stuff because an extra day the money is in their account is an extra day they earn interest on it.

When a bank processes a credit card, the money is deposited automatically. When PayPal processes a transaction, the money is stuck in the virtual limbo. We need automation, otherwise PayPal is not much different from regular banks.

Symbox: My PHP Symfony helper on GitHub

Today, I created my first GitHub public repository aimed at making new Symfony setups a bit simpler.

It’s called Symbox, and you can find it at http://github.com/AndreiRailean/Symbox

Basically, it’s an apache config file and instructions on how the directories must be structured so everything works without much effort. I use this approach on my localhost and a few other servers not only for Symfony but for other php projects as well.

On Profile Pictures and Web System Trust

I like Gravatar (http://gravatar.com) because it allows usage of data without authentication. I tend to use the same picture everywhere: Facebook, Twitter, Skype, LinkedIn, YouTube. I like the fact that once the system knows something about me (my email address) they can go out on the web and get more information about me without my explicit involvement.

Most systems can’t get it together. When I was at Yahoo!, many people were brainwashed to believe that there must be THE ONE site user will use. I have a suspicion that it’s the case for other companies as well. So Twitter folk want to be self-contained and so do Facebookers.

Times are changing. Now it’s way cooler to cooperate. Why not delegate some services to other providers? I guess it could be a cost saving measure. Why pay to someone to handle your profile pictures when they are trivial to host? And if we do pay them, will they do a good job?

I like the features of YouTube where when you like a video it gets automatically shared on FB and Twitter. Why can’t something like this be enabled for web avatars? Why can’t uploading a new profile picture to Gravatar broadcast this to other platforms? How about when I change my picture and link a Twitter account to Gravatar, @gravatar user posts a status message something like “@andrei_md has changed profile picture to http://www.gravatar.com/avatar/d9bf8ae88423aa977274f4a6b7499c5b”. Twitter would then be able to consume this link themselves and do that magic of updating the picture using their own API.

The main point of this post is not the algorithm for updating profile pics.

The point is that big systems should start trusting each other and become co-dependant for the benefit of the end user. If Gravatar knows what my twitter account is and twitter knows what my Gravatar account is, they could start talking to each other about me more often.

Idea: Gravatar-like API for Twitter user images

What if you could MD5 a users email address and ask Twitter for user’s image icon? In fact, this could also apply to Facebook, Google, Yahoo and others. Well, maybe not Yahoo as they are too paranoid.

Maybe Gravatar could be the world’s Avatar authority this way as well. At certain intervals they would fetch avatars from all major networks and use the most recent one. What’s better, all the networks could use Gravatar unless the user chooses to upload the image. This way setting an image on Facebook would update images on Gravatar and everyone who uses them.

Regardless of how this develops, I think lots of people agree that there’s a need for an interconnected avatar system.

Maybe soon we’ll all have unique IDs which are MD5 hashes of our emails on every network.

Rel=Canonical Snippet for Shopify Template

Here’s a quick snippet I put together to have each page be canonical to itself. I need this to avoid duplicate urls for same content, which often happens when there are GET variables involved for affiliate tracking etc.

It would be much nicer if there was a page_url variable like page_title. In that case it would be as simple as <link rel=”canonical” href=”{{ page_url }}” />

Word of Caution: Paginated collections report the first page as the canonical, which may mean that your site will not be indexed quite the same.

Here we go:

meta-canonical.liquid

{% case template %}
{% when ‘index’ %}<link rel=”canonical” href=”/” />
{% when ‘product’ %}<link rel=”canonical” href=”{{ product.url }}” />
{% when ‘article’ %}<link rel=”canonical” href=”{{ article.url }}” />
{% when ‘blog’ %}<link rel=”canonical” href=”{{ blog.url }}” />
{% when ‘collection’ %}{% if collection.url != ” %}<link rel=”canonical” href=”{{ collection.url }}” />{% endif %}
{% when ‘page’ %}<link rel=”canonical” href=”{{ page.url }}” />{% endcase %}

Shopify Review: Good for Tiny Stores. Bad for Big Ecommerce.

Summary: I don’t like Shopify because their Checkout flow is weak in features and is not customisable.

Recently I’ve put together www.paintaccess.com.au online store using Shopify. Shopify is a hosted ecommerce platform. To launch, it was the best choice and it probably would still work fine for us if all we were doing is selling t-shirts to one-off customers.

To start, I’ll outline what I liked about Shopify and why it was chosen against other competitors.

Instant Start
You can literally start your shop in minutes and pay no signup fees. All you need is a valid credit card.

Nice Web Interface
Anything you can do with the store is possible through a web interface. All templates and other code is editable. Pages, redirects, file managers - everything is there in the admin area. Everything works in a web 2.0 way - not many page reloads. Overall the experience is very smooth.

Initially I tried developing the theme using a regular code editor on my mac and test with Vision. I quickly outgrew what Vision had to offer. I wanted to work with snippets, layouts and link lists but Vision is not made for that as I was told by one GitHub user. I switched to using the admin interface and although it’s quite slow compared to regular dev flow, I can get what I need done.

Attractive Templating System
I am able to achieve a lot of interesting things using the page template + layout + snippet combination. The “Liquid” template language is pretty immature, but so far it works. At first I was trying to think about performance. Later I decided that I need to focus on features and let the Shopify team deal with performance, even if I have to iterate through the same multiple interleaved loops with conditionals on every page. Not my problem. I’ve been finding creative solutions to problems in CMSes and other web systems for quite a while and can hack quite a bit up in almost any programming language.

Integration with our Payment Gateway
We use SecurePay (Australia) and PayPal and they both are easily connected to in Shopify, though when you use PayPal the users are not sent back to the site to complete the checkout process and it doesn’t get reflected in Google Analytics.

Smooth Product Management Interface
Easy to write the product up and add photos and variation. That was enough at the start.

No Login for Checkout
We specifically searched the web to have a solution that will not force users to log in before checkout and shopify was ready for exactly that. Though we shortly realised that we do want our customers to have a choice of logging in.

Okay, okay. Before you either get sold on Shopify or get bored reading this, I need to tell you what I don’t like about it. I made sure I understand the product before I decide to switch to something else.

The biggest thing I don’t like is the weak Checkout. When you’re searching for a payment gateway, you always come across those who offer you a “hosted payment page” - essentially a page where you’re redirected away from your shop to some other site. This is essentially what you get with Shopify. Customers get sent to a bastardised checkout flow that is functionally outside your control. All you can do is change the CSS to get it closer to your shop’s look and feel. Otherwise it just looks grey and uneventful.

As the store was being developed and business was making forward plans we realised that having control of the checkout flow is one of the most important things. We need to allow the customer to create an account and be remembered on the system. We want customers to come back and they want the system to know what they want. You don’t get that with Shopify.

Another reason for having control of the Checkout was the need to plan for and implement an affiliate program through a partner of our choosing. With Shopify this is not possible. If only they allowed checkout code to be customised using Liquid I’d be much happier. I don’t even care that checkout is on a different domain. I just want to control user’s experience and store behaviour.

We want the customer to be able to save their credit card details if they so choose.

The biggest reason why all this is happening with Shopify is because they are small. I don’t know how many people they’ve got. It feels that there are about 10 people including admin staff and their primary focus is on developing the Shopify apps platform. Apps are a good idea for them because it’s another avenue to make more money by charging commissions.

Abandoned shopping carts are another item of interest lacking from Shopify.

Another weak thing is lack of dynamic listings that can be programmatically narrowed down by people visiting our site. I can’t send a customer to a page full of brushes and have them narrow it down by specific type and/or manufacturer. You have to build it manually in html or using the triple conditional loop mentioned above. Even with all the looping many things must be done manually. And when the shop gets more products, you need to remember to update all the static HTML to include them (for ‘advanced’ functionality). Get this: there’s no way to programmatically get a simple list of manufacturers or vendors or product types. Copy-Paste, Search-Replace.

At one stage I was considering writing a different admin interface by taking advantage of their API and have that new interface create all the static stuff. Later I decided it’s cheaper to move to a different provider who’s got more dynamic logic.

There are a few things I might be forgetting. I’ll probably end up coming back to this page to edit it for more structure and content. For now, I hope you understand that I’m not entirely happy about Shopify when thinking about moving forward.

Conclusion: Shopify is a great platform for very small operations who are happy with available templates with customisable styles. It’s also great if you’re just starting up and all you want is to experiment with products and prices and don’t require much dynamic functionality.

Once you’re all set up with Shopify and want to expand your store’s functionality, you will need to make an effort to switch to a more capable system. Or you could put your expansion plans on hold and take a vacation or two until new Shopify features are released.

Ask your questions if you need any help.

Domain Hash Method

Here is a simplified way to verify domain name ownership by third party services.

Method:
Store a hash (e.g. MD5) of domain password in a TXT record in the domain zone.

Example:
blog.andrei.md  TXT  publichash:sha1:aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

When I go to a blog provider and tell them to use blog.andrei.md as a domain name, instead of just trusting that I own the domain, the verification goes something like this:

I create public hash:
sha1(“hello”) -> aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d
and update my DNS zone to reflect that

I supply my domain name to the service provider:
blog.andrei.md

Service provider looks up the TXT record and extracts the part that starts with “publichash:” and ends with a whitespace character (publichash:[\w]+). From there, they determine that the hash is in sha1 format and extract the hash.

Service provider asks me for a password.
I enter “hello”
They compute and verify that hashes match

That’s it, a service provider has verified that I know the domain password and can assign it to my account on their system. This is kind of what Google does when you verify their domain with them. Google asks you to do it via a CNAME, which I don’t find as pretty because you’re polluting your domain space with Google-specific one-time-use record which serves no purpose other than to verify ownership.

Now, in order for domain to point to the new service provider, we’ll still need a CNAME record (good) or an A record (bad) so that browsers and other systems can resolve the address to the new system.

In some cases this can be done with just a CNAME record. For example imagine there’s a blog system on blog.example.com. I signup and get my new shiny blog address andrei.blog.example.com - YAY! Shiny it may be, but I still want to keep it under my domain name for more reasons than one. So I create a CNAME record like so:
blog.andrei.md CNAME andrei.blog.example.com.

The imaginary interface at blog.example.com would then ask me to for my new domain name and after looking up the CNAME record and checking that it points to my blog subdomain on their system, they enable it. This would do the trick in most cases where there’s a one-to-one mapping between the domain and the service provided.

However, if you want to represent the domain somewhere or add “verified” links to it, another system is required. What’s a verified link? If you’re leaving a comment on some blog, how does that blog verify that the URL that you leave in the “www” box is truly yours?

I could also wildcard the whole domain to this one password like so:
*.andrei.md  TXT  publichash:sha1:aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

Of course, if a hash is out in the open, anyone can retrieve it and try to reverse engineer the password on their super hardware. We wouldn’t want to take all the fun away from life and make it super secure, would we? However, I believe that the convenience could outweigh the occasional potential security risk.

Anyway, take it or not, it’s just an idea that I need to get out of my head and into the net so it doesn’t get lost and I’m free to think of something else.

I am Andrei Railean of SITER Internet Solutions and I make internet better by performing worldwide web development and maintenance projects from Sydney, Australia.