IndividualWeb

Ideas of March.

March 19, 2011

Oh blogging, oh blogging. Thy threshold is low, but the maintenance is big.

I like reading blogs. Especially those that have categories and tags to filter out all the stuff you don’t want to read about. The only thing that bothers me is that you often have to read a lot of blogs to find updated material on the things I care about, especially in the PHP community. Great post should be advertised and marked cool! If only the people who do have some cool code to provide could blog more frequent with a lot of cool code!! Sigh.

It’s a challenge. I know that, having some blogs out there with different kinds of content, updated every now and then. Blogging takes time if you want to do it good. People want an updated blog. Blogs does not bring that big of an income. But still, people keep blogging, I keep blogging, and you keep blogging. Every once and then someone finds your post in a time of need, and the purpose of the post is fulfilled. Do not blog for the masses, blog for the few that can evolve into masses. Blog for yourself. Blog to make a history, if only your own blogging history! That is a best practice!

Leave a Comment » | Best Practice, PHP | Permalink
Posted by individualweb

Send large emails in php

March 17, 2011

I’ve encountered this problem once a long time ago, and used a lot of time finding a solution back then. Probably because no one really directly issued this problem.

When you send large text in your mail, specially HTML, you have to remember to encode the message right and chunk it. Why? The email standard RFC2822 only accepts line lengths of 998 chars, and if you send longer lines you probably encounter a lot of problems in different email clients. This may be line breaks or spaces after every chunk of 998 chars, that could be in the middle of an HTML tag or link, making the email body a mess.

To avoid this, you have to use base64 encoding on the email body header:

“Content-Transfer-Encoding: base64\r\n”

The second thing you have to do is to encode your content string with base64 and chunk it into chunks before appending to the email.

chunk_split(base64_encode($content))

base64 encoding is something email clients can read and because the sting of HTML is encoded into this format you don’t get the spaces between every chunk of content when the client displays the content.

These two lines is the only thing you probably need to append when you ha long text or large emails with data longer than 998 chars. Today I encountered this problem again, and I knew about the solution so I knew what to google to find the right answer. But I did not find it right away, because there was not any really good, and short, explanation anywhere that said exactly what I needed to do.

1 Comment | Debug, HTML, PHP | Permalink
Posted by individualweb

Problem with getting JSON from PHP using AJAX

March 3, 2011

I got this problem when I wanted to get back a json produced in PHP. Naturally, I used this header:
header('Content-Type: application/json; charset=utf-8');

It did not work, and that’s the one that everybody said I should use. So I tried different. I tried this:
header('Content-type: text/plain; charset=utf-8');

And it worked! In FireFox, in Chrome, in IE 8 on my computer, but it failed on IE 8 on my co-workers computer. WTF? Yep. Somehow it failed, and it needed a fix.

Since it failed, I can tell you that in AJAX the return value was not the expected one. I used jQuery and expected the dataType: “json” to work. jQuery does the evaluation of the data and creates a JSON object. But not this time. It failed. In IE8 the header seemed to be ignored and the value returned was wrapped in <html><body></body></html> – and yes, it seemed to be a common error somehow, except that none of the solutions mentioned that seemed to work for others worked for me. I even tried some really simple code, and it failed – but I managed to get it to work if the filename actually was .json – but then I could not use PHP. Or could I? The solution was this, with two headers in PHP:

header('Content-type: text/plain; charset=utf-8');
header('Content-Disposition: inline; filename=response.json');

And then do the

echo json_encode($array);

And voila, it worked.

1 Comment | AJAX, JavaScript, jQuery, PHP | Permalink
Posted by individualweb

The blessing in documenting code

February 23, 2011

I’m currently working on this framework in PHP but I was very unsure about what features to add. That’s why I began to document in the code at once, but it didn’t work right. It was too many changes in the code to begin with and I didn’t really know what I wanted – so the documenting was a messy draft that had no effect and became soon outdated.

But, that’s not the whole story. A framework need a good API, and I began working with it and found that it was actually a lot of fun. Firstly I listed every method I could think of, and then I began to write the functionality of each of them including examples of their usage. This way I found a lot of things to improve on the method functionality, I got a really good flow on programming them. It resulted in a really great API documentation as well.

What did I learn?

Different projects need different types of documenting. If you are unsure about your project try a more planned approach and then when the project is finishing up – then write the documentation in code. Other projects that has a lot of repetition in how methods act(like getters and setters, or getall_xx_fromdatabase) – they are easy to document in the code as PHP Doc because you know how to implement them and what you need them for. There is no point in building an API for a site like that. It’s not about what works for you, it’s about what works for your project.

This approach works also on testing. There is no point it creating unit tests for a framework that is under developement and have no real structure in what methods return or work. If you have a project with a lot of methods where you have define what they do, you can easily write Unit Tests for these methods. But if you, as I have, a method that does a lot of different stuff – then the best way is to have a test page and test alongside documentation. Later on, when you do a change, you can check if the test page renders the right way. When you have finished you can polish this test page, and make UnitTest for every possible use case.

Learn how to be flexible in how to document. When you do it right it might be fun. But do document!

Leave a Comment » | Best Practice, Debug, Documenting, PHP | Permalink
Posted by individualweb

Is PHP frameworks bound for patterns?

February 12, 2011

I was looking into the code of some common and uncommon PHP frameworks, and all of them proudly showed off their implementation of MVC pattern. Some of them were using a variety of other patterns and techniques – and I was wondering, do they really have to?

I was all confused when the different frameworks had their huge folder structure and a lot of stuff you had to do in order to echo out “Hello World”. And they said it was easy and fast. The fastest and most easy is still to write echo “Hello World”.

Its ok and good to implement MVC structure on a framework – it’s almost a nessecity, because programmers all know what it’s about and can easily adjust. But don’t tell me that your framework is special when it’s not. Dont tell me that it’s simple when it’s not.

I think, on the framework I’m building and the projects I’m working on, that the framework frees me from being bound to MVC and patterns (or was it the other way around, that they bind me to use MVC and patterns?). Instead I create my own based on the needs of the site (it be an abstraction of MVC or other patterns). Frameworks, in my opinion, is for abstracting away some code and make it easy to write the application. I like thinking new and creative.

But the again. I never liked frameworks. So my vision is clouded in the matter, I admit that.

Leave a Comment » | Architecture, Frameworks, Patterns, PHP | Permalink
Posted by individualweb

Sexy Code

February 5, 2011

Why does JavaScript get all this attention and rethinking these days? Wherever I turn my browser there is a lot about jQuery, node.js, prototype etc. Why cannot the same techniques be applied server-side, on PHP? Aint PHP sexy? JavaScript was not sexy at a point until someone made something with it and it became fantastic and easy. How did that happen? Are JavaScript developers more creative? Is it a better and more flexible language? Is it because its front end and handles interaction?

Well. I’m going to try to code sexy when I do PHP. Right now I’m writing this html parser that is neat and cool. I want to be a part of server-side language revolution with PHP. It has potential! I don’t want to hear about Ruby on Rails, .Net or Python – lets empower PHP, and get rid of all that crappy code out there.

I’ve programmed a database class multiple times, and its an evolution. This happens in every aspect of my code all the time, and that’s really a journey. Here are the database example:

First it was spaghetti.
Second time I made it in a config file.
Third time I switched out mysql with mysqli and made some functions.
Fourth time I made the database a class.
Fifth time I accessed it through a controller and DAO classes.
Sixth time around I made it a singleton and reused the connection.
Seventh time I added pconnect and it became persistent.
Eight time, then the database object extended the mysqli class.
Ninth improvement was to make a ORM expand the connection.
Tenth evolution was to make an easier access for the creation of advanced queries.
Eleventh time, I made the ORM chainable and combined more advanced queries to it.
Twelfth thing was to improve the to interact with different kinds of result sets.
Thirteenth, in the end, the chainable database singleton class extending mysqli got wrapped in a function for easy access.

How do you like this kind of code:
echo query('tablename')->columns('id, name, regdate')->where('id > 155')->orderby('name')->asc()->toarray()->html();

And the future still brings more:
- The code to support multiple different databases
- Extends the support for joins and relations
- Add better template engine to the output presentation
- Make the mess faster

That is what I’m currently working with…

Leave a Comment » | Best Practice, JavaScript, jQuery, Objects, Patterns, PHP | Permalink
Posted by individualweb

Readonly dropdowns

January 21, 2011

As a developer you probably meet this problem at one point – how to make the dropdown select a readonly element. This works just find with other inputs where you can say readonly=”readonly”, but a <select> does not have this option – it has only the disabled=”disabled”, but this will not post the element.

My solution is a little bit of jQuery (this can be done in plain javascript too, but it’s a bit longer code), that disables all off the <option> tags that are not selected – then the <select> still is available for post with the current selected <option> tags and with the rest disabled so that the <select> can be viewed but not changed (Read Only).

The code for readonly:
$("#selectid option").not(":selected").attr("disabled", "disabled");
The code for resetting:
$("#selectid option").not(":selected").attr("disabled", "");

Hope this helped.
Do you have a better/easier solution? Please share.

Leave a Comment » | HTML, JavaScript, jQuery | Permalink
Posted by individualweb

Sticky Note with CSS and JavaScript

December 29, 2010

I wanted to se how easy it was to make one of those yellow sticky notes with CSS and a little bit of bonus javasrcipt. Current version is a bit flawed – but works, is easily modded, and shows the idea.

To see the demo, click here

This can be made more simple by removing some JavaScript functionality. For instance, It’s really an overload to include jQuery and jQueryUI for the small stuff it adds, when it can be done in some simple lines of good old JavaScript – but if you have included the libraries already, then use them. This should work cross browser as well.

Features:
- Hidden by default, opens by click
- Different styles to different points
- Lines made in CSS
- Linetrough points by click
- Gap at top and bottom + close button at top
- Draggable

Lacks:
- Toggle on/off by click not implemented
- Some smaller bugs
- No real modifying functionality (like adding/removing/editing)

Leave a Comment » | CSS, HTML, JavaScript, jQuery | Permalink
Posted by individualweb

So, how do a programmer learn CSS?

November 7, 2010

I’m a programmer. I like to design stuff too, so I have a fair amount of knowledge about CSS. But how do I learn CSS even better?

Well, I stumbled upon this article about css minifier comparison: phpied.com – CSS minifiers comparison

CSS Tidy seemed to be the obvious best choice, so I thought I’d take up the challenge and make my own CSS minifier – based on the Ideas I had when I started to think about the logic behind. That’s where the fun began.

After some hours of work I managed to create a simple CSS minifier with PHP, that still is a way to go to match the capabilities of CSS Tidy, but where I even managed to be better in some cases. I still see a lot of improvement potential on my small script (~13 kb and counting – CSS Tidy is ~100kb), so hopefully the improvements can make my css files even smaller and crush the competition :-p

There is still a long way to alpha version(probably tons of bugs to fix before it’s stable), but when I come to it I’m probably going to put it out there as a web service.

What did I learn so far?
- A lot of CSS tricks!
- How to write CSS with more confidence.
- When shorthand css is favorable (“always” is the wrong answer).
- CSS never really stops being a mess :-p
- You can write very simple css, creating huge css files, and then easily minify and optimize size when in production.
- That the effort of creating very small css from scratch become somewhat pointless.
- How to write CSS the best for optimized minification.

Leave a Comment » | Best Practice, CSS, PHP | Permalink
Posted by individualweb

Remember your customer

October 16, 2010

When you design or create a web page you have to remember who your main customer is. Or, do you? Is design and usability all about satisfying the supposed impression made by your customer?

I would say yes, and no.

Where I work, the business is all about money – and the ones that pay is not the typical web user. The ordinary customers to the site is all kinds of people, from the web novices to web experts. When we program and design, we make it as easy as possible. The UI is not very intuitive, but it is understandable. There is always a call to action, like “click here” or a description to simple tasks. I don’t always like this, but we need to do it this way if we want to reach out to the masses.

On the other side, the projects I do at home – they are partly for my own interest, but also part of using (hopefully) intuitive and creative solutions to attract the users. A way to get customers. A way to create attention. The average web user should figure out the features, and the design should be obvious but with features that are not that obvious until you start using the site more. This is on my premisses and terms, not on the end users – and there really is no support department to call if you are a novice and need help.

The third scenario is websites where the main feature is to test new features, new ideas, new ways to present and manipulate data. Typically a test site for new features in for example HTML 5, CSS 3 or some fancy JavaScript. Often these are a bit over the top creative websites that even pro web users have to use some time to tame. I think sites like that is mostly to test the web, to suggest new ways, to be ahead of the developement and to not care all about what will be a standard UI at the end to the common user. We need these sites.

These three examples are three different ways to program and design. What your goal is up to you to find out, but when a blog – or some expert – say that this is a trend, and that is a thing you should have, or a menu should look like this and a button like that – you really should think about the consequence. Purpose, content, design. They go hand in hand.

Leave a Comment » | Best Practice, Design | Permalink
Posted by individualweb