akrish

I learned PHP in January and February of this year, using it for a couple of websites that I’ve written (including this blog). Over the course of several projects, I’ve become pretty familiar with the language, the online documentation, and all the in’s and out’s of PHP. I also first touched perl at the beginning of this year, but only for a short little project. This summer, most of the programming I’ve done at work has been in perl, so I’ve gotten quite familiar with it as well. Now that I know both of these pretty well, I have a little more flexibility in designing and implementing my ideas. That being said, every time I start a project, I have to think about which language is ideal. Now, I’ve gotten pretty good at this, and I know when to use perl over PHP and vice versa.

For web scripting, I prefer PHP. I really like that PHP can be embedded into html. It’s really quick and easy to write some pretty powerful web pages with PHP, and I’m a lot more comfortable with web forms in php over perl. I also have an incentive to write web sites in php, because my local server doesn’t actually execute any perl scripts called by the browser. So for most of my web stuff, I use PHP.

On the other hand, shell scripts are a lot easier to write in Perl. With perl, it’s really easy to interact with the shell and execute shell commands, and I also like that you can easily pass in arguments when you call a perl script from the command line. What’s more, with the default file handlers in perl, it’s easy to take inputs and have a more interactive shell script in perl. Although both languages have the capabilities to run through the shell, I just find it a lot easier in perl.

I also prefer perl for text-processing, most because it’s a lot easier to use regular expressions in perl. They “~” syntax is very simple, and a lot more readable than the “preg” functions in php. I also find it a lot easier to work with files; the perl file-handle data type makes reading and writing to files really clean. Again, PHP has all the same functionality as perl, it’s just a lot easier in perl, which is why I prefer it for text-processing.

Along the same lines, XML parsing is a lot easier to do in perl. Actually that’s the reason why I decided to write this article. I used to be parsing my xml feeds to this site using PHP’s xml parser, but have recently switched to a perl parser that I wrote yesterday. Because perl has such extensive libraries (i.e. CPAN) there’s less need to re-invent the wheel in perl than there is in PHP. PHP is a pretty powerful language, but because perl has a huge developer community that contributes to CPAN, a lot of functionality is constantly being added to Perl, while PHP isn’t such a dynamic language. In that respect, I prefer to use perl for a lot of things.

So why use php at all? For one thing, php is a higher level language. Most of my code remains pretty clean and tidy, and I don’t have to worry about a lot of minor issues, like variable declarations, that I do have to worry about in perl. I also like how php function declarations include the input parameters, whereas in perl they’re passed in to the special @_ array. PHP is quite a bit simpler to use than perl, so I prefer it when I don’t need the additional power of perl.

Recently, I’ve taken to using perl over PHP because I’ve been using perl a lot more recently and I find that I can do everything that I want to in perl. In PHP, I still can do almost everything that I need to, but sometimes it’s a little syntactically awkward and messy, which is why I prefer perl. I’ve started to figure out which language is ideal for the task at hand. As I learn more languages (I’ve started looking at python), I’ll naturally be better equipped with solutions to a given problem, but it’ll be harder to decide which language to use. Personally, I see this as a good thing, because it’ll be a lot easier complete my tasks if I choose the correct tools.

I just finished my summer internship at Tellme yesterday, and it was an amazing experience. Not only did I have a really fun time working there, but I definitely learned a lot and I also got to see the infrastructure of a moderately sized company. I was a applications developer intern, so I ended up doing a lot of coding, but everything I did there was very different from any of the coding projects I’ve worked on for fun or for school. A lot of the differences were essential to running the company, but some of them made things run a lot slower. Most of them however, were really good programming practices that I’m beginning to pick up and notice in my own coding. Here’s some of the things that I learned from my projects, the employees, and of course, my fellow interns:

1. Consistent Coding Style For the most part, code is pretty hard to read. You probably know that if you’ve ever wanted to add to something you wrote a couple of months ago, and then figured it’d be easier for you to start from scratch than to decipher your code and augment it. When working on bigger projects though, it’s a huge waste of time to start over, so you need to make your code as readable as possible. It’s even more important on team projects when other people will be reading your code and using it or adding to it. On these projects, it’s essential to have a consistent and defined coding style that’s used by all members of the team.

One of my projects at Tellme involved abstracting some preexisting code, so naturally I had to read through all of it. There was one file, that was about 2500 lines long, incredibly dense, and very unintelligible.

It took me about a two full days to go through this one file and figure out what was going on, and this was largely because the coding style sucked. Anyway to make a long story short, having a consistent coding style really adds to the productivity of a team, especially on large projects.

2. If it’s not tested, it’s broken I was amazed at the level of testing that went on at Tellme. Even things like content changes to their corporate website would be reviewed by a pair of developers and then by a QA engineer. It was a standard practice to review these minor changes on four or five different browsers, which I found to be a bit excessive, but also very thorough. It was a marked difference from the level of testing that goes into my own projects. On my projects, I used to just test until it works a couple of times, but after seeing how production-grade software is tested, I’ve started to write testing suites and actually test my projects.

3. Production Quality As I spent time at Tellme working on their projects, I realized that everything I’ve ever coded hasn’t been suitable for production at all. In fact a lot of what I do is take an idea to proof of concept, and then drop it. I never spend time on exception handling, error checking, parameter validation, documentation, or even optimization, but all of these are essential to making software actually usable. It’s interesting to see that programmers end up spending most of their time on these things, rather than the things that I end up doing. They code a lot, but very few of them are actually designing new things. A lot of the time they work on making things robust, and actually usable.

4. Bug Fixing Most of working on a development team is spent fixing bugs. It’s something I don’t really look forward to when I think about getting a job. I’d much rather be actually working on something new and innovative than fixing bugs for a career. Pretty much the first half of my internship was fixing bugs on Tellme’s website, and that was actually really boring. Granted it was important and needed to be done, but the work wasn’t very intellectually stimulating at all. I guess it goes with making production quality software, but it’s pretty monotonous to be fixing bugs all day.

Speaking of bug fixes, the other interesting thing I noticed was that Tellme would release software with bugs in it all of the time. Apparently it’s a pretty common practice for companies to do this so that they can meet their deadlines. It makes sense to me that they need to release software by a given date, so they purposely don’t address some bugs, but it’s also very odd for me, because whenever I see a bug in my software, I immediately fix it. I guess that’s one of the differences between a side project that you work on in your free time, and a project that you work on for a company.

5. Programming Overhead This is one of the things that makes me not really want to work for anything but a startup, but the developers at Tellme are actually only writing code for maybe 25% of the time they’re working. So much time is spent communicating, maintaining servers, interacting with huge code bases, and all sorts of other stuff, that they don’t actually spend that much time coding. A lot of what they do is necessary: people need to communicate on team projects, servers need to be maintained, and when you have a lot of code, you need to have some way to store it (i.e. version control systems like csv or svn). These just aren’t thing’s I really want to be doing for a career, at least not right now. I want to spend my time designing innovative technologies, and writing really cool software, rather than on maintenance. Seeing this at Tellme (which is already a pretty small company) made me really want to work for a start-up, where I wouldn’t have to waste some much time on overhead.

There definitely are more things, which is why I’ve titled this part 1, but I’m having some serious writer’s block right now, so I’ll get to the other stuff later. I also plan to write about the more general lessons (not related to programming) that I learned at Tellme. A lot of the things I didn’t like, aren’t really specific to Tellme, but more are causes of working at a company with a lot of people. These are all things that are essential to company infrastructure, but annoying to deal with as a developer. I’m sure I’ll get used to all of these things when I actually get a job, but as a student, they’re things that make me not really want to get a real job. Overall though, I really enjoyed my time at Tellme, and it was an amazing learning experience. I highly recommend getting an internship, and I’d be thrilled to get another one next summer.

Since January, I’ve been working on and off on website/application called WeNote that I hope to release for the last time in December of this year. Now that I’m pretty much done with the structure of this blog, I’ll be talking about that project a lot mere in here. Anyway, This was my first time making a production quality application so naturally I made a lot of mistakes. I’ve learned a lot from these mistakes and now feel a lot more capable of making something that users will actually go to and be interested in. I’ve already released two versions of the website, both of which have been met with brutal critiques from my friends and very little site traffic, so I shut the site down and am rebuilding it from scratch. Although there were also a lot of back-end mistakes that I may, here are 7 of the Web Design-related mistakes that most web designers will have to learn at some point.

Version one of WeNote was absolutely terrible. The layouts of pages were not thought out at all and inconsistent across pages, the color scheme was terrible, content on pages was poorly written, and the site just didn’t look appealing. In my defense, I didn’t spend much time working on the user experience because I was just learning PHP. I focused a lot on the back-end, which even still didn’t turn out that well. Version two was a significant improvement from version one in terms of functionality, but visually it was still pretty bad. When I released this one, I told all of my friends to use it, and they all made accounts, but I was getting no traffic. I attribute most of this failure to lack of a good user experience, because the back-end was pretty functional. With that introduction, here’s the list.

1. User Experience is really important: This one seems obvious, but it still needs to be stressed. Without an amazing user experience, users will not come to your site, regardless of how functional it is. This is a big problem for me, because I’m less interested in layout design and graphic design and more interested in the back-end code for the site. I think a lot of hackers prefer to work on interesting code (i.e. back-end) than on the stylistic needs of the site, but both aspects are essential to any good website. Every time I showed off WeNote to one my friends, he always said something like, “The UI sucks.” I really should have listened to him and spent some time on the UI, but it was really easy for me to procrastinate. As a result, for the third release of WeNote, I’m actually building an HTML mock-up of the site before I even start on the back-end, so that the site has a decent user experience.

2. Attention to Detail: This one I actually learned from building a different website, but it’s incredibly important. When styling a website, every single detail matters. My friend and I co-operated on a website called uclinked a couple of months ago. We didn’t spend much time on the site (it was a pretty simple idea), but everyone who I showed the site to noticed a smudge in our banner image. It really took away from the sight because that was the first thing everyone noticed, and it immediately gave them the impression that the site was poorly made. From this experience, I learned that every single detail matters. On my mock-ups for Version 3 of WeNote, I’ve spent a lot of time making sure that colors blend will, that images and borders line up and are consistent, and that every element is exactly where I want it and looks exactly how I want it to. It’s time consuming and tedious, but it’s essential to building a successful site.

3. Navigation: This is actually related to functionality of the site, but it contributes a lot to the user experience. When a user visits your site, you want them to be able to find what they want easily, so you need to have a very clear, simple navigation system. Navigation areas aren’t the places to show off your creativity. These guys have to be easy to find and easy to use, otherwise people will get frustrated with your site, and they’ll never come back. Don’t try new navigation techniques on your sites. People expect to find navigation elements in certain places, usually right below the banner, or on the left side of the page, and if they don’t find them where they expect, you have a problem. You can be creative with your buttons and any animation you want in your nav bars, but make sure people can find them and use them very easily.

4. CSS can’t do it all: It’s time to face the facts, you’re going to have to use some images to spice up your site. As amazing as CSS is, it’s not going to make you’re site look good on it’s own. You’ll need some Photoshop-ped or GIMP-ed images around your pages to complete the user interface. The problem here is that it takes a long time to learn how to use good image processing software, and a lot of hackers would rather be coding that messing around with GIMP. Unfortunately, it’s something that has to be done, and it really makes your site look better. With plain CSS, you can make your site functional and usable, but it definitely won’t be very cool looking.

5. Textual Content: If you have a lot of text on your web pages, it’s important that every word is carefully selected. You don’t want too much text (unless your writing articles), but your text must convey your message to the users. For WeNote, I had text on my home page that explained what WeNote was and why someone would want to use it, but it was pretty wordy, and not even very explicit. It might be a good idea to get someone who writes really well to come up with blurbs for you if you’re not very good at it (like me). It’s also important to place text in places that people expect it, and also make sure that the font is well sized and easily readable.

6. Design for your audience: When styling a page, take some time to think about what the page is supposed to be, and what your users will expect. For example, there’s a pretty standard template for online newspapers with Old-English-y font for the header, a navigation bar for the sections of the paper, and recent stories on the front page. You can also think about what your users like, and theme some of your images, fonts, colors, etc. around what they like. If your page is more artsy, you may want your header, and buttons to reflect that blurring into the other elements. Maybe you could use some really nice nature picture as part of your banner. At the same time, don’t be too cheesy or too exclusive. You don’t want to intimidate possible users with your design, so keep your theme a little general. This is something I haven’t exactly figured out yet, but I’m working on it.

7. Design for all browsers: Internet Explorer, Mozilla Firefox, Apple Safari all behave slightly differently when it comes to CSS and images. It’s terrible that things aren’t standardized, but as a website designer, you need to be sure that regardless of browser, your users have a great experience on your page. Test your site on all browser to make sure that it works properly and that it looks good. Have separate style sheets to load based on what browser is being used (Javascript can detect browser and load the appropriate style sheet). One of my friends made me a banner for WeNote in photoshop, and it looks great in Firefox on my Macbook Pro, but in Safari, the colors are purple, rather than blue, and the banner doesn’t fit with the rest of the page. As a result, I’m going to have to change my banner image, even though what my friend made was really cool. Compatibility with different browsers is essentially to attracting a wide user base.

So that’s some of the things I learned in the last 8 months of web design. I’m still consider myself a novice at it, so I’ll be learning a lot in the future and I’ll write about some of that too. I hope this is useful to anyone interested in designing a website.

I’ve been playing around with scheme a lot in the past couple of days and it’s gotten me thinking about design strategies and how to use less code to get things done. Although I haven’t been doing much interesting stuff with scheme since I re-started using it, I have been reading about some of the more complex functionality of the language, and I hope to start writing some productive code pretty soon. Already I’m noticing tons of things that can be simplified through the use of scheme, and hopefully I can take advantage of this with my projects. I’m not gonna explain what scheme is so if you’re interested visit the link above.

My introduction to scheme came about a year ago, in an introductory programming class that was taught entirely in scheme. At first I hated the language because it was so different from Java and everything else I knew (most of the other people in the class felt the same way), but the language really grew on me as I realized how elegant it is. The course didn’t cover all of the amazing things about the language (i.e. macros, I/O, and using scheme as a scripting language) but we did hit some of them like higher-order procedures, scoping, and different types of recursion. Learning these concepts last year made it a lot easier for me to go back to scheme and pick things up where I left off, so that I can now focus on the stuff I haven’t already learned.

So why is scheme so amazing? First off, higher-order procedures are awesome. I know other languages have them (python), but they’re still really cool and very useful. There are so many situations where I’d want to pass in procedures as arguments, or return procedures from some other procedure and a lot of modern scripting languages are really restricting because they don’t allow you to do that. Secondly, everything can be written in very few lines of code, so that you’re programs stay readable. Most functions that I’ve written don’t exceed 20 lines, and readability is key on larger projects where you’re going to come back and modify stuff. Functions stay small because recursion is the norm in the language. Rather than iterate through things with a looping construct, I’d just use recursion and save a couple of lines of code. Finally, macros. These guys are pretty amazing. They let me write/modify my code at runtime. They let me create special forms and new syntactical structures that I can use later on (like if I need to use a certain structure several times I’d just write a macro for it to keep my code simple). Macros let me customize the language so that it’s perfect for whatever project I need it for. With all of these cool and very useful features, it’s amazing that so few people actually use scheme (or Lisp for that matter) on a daily basis.

There are a couple of ways I would use scheme on my current projects that I think would make my life a lot easier. One definite way would be to interface with mysql and really cut down the number of functions I have that query my database. I’m thinking I would have only 2 functions that generate Insert and Select statements (or one for each type of statement) and then one function that gets the statement and then executes it. Then I can have some other functions that modify/manipulate the mysql results the way I want them to. What’s cool is that I can pass in all the manipulator functions to the general mysql-interaction function so that all of the handling of mysql resources occurs in the same place. Then what I can do is build a macro that performs the mysql command so that I don’t have to make all these function calls every time I want to query mysql; I’ll just have to write one word. This idea hasn’t been fully thought out, nor have I even started to implement it, and it may very well be as lengthy as writing tons of mysql interaction functions, but it seems like it would make interfacing with mysql a lot easier.

Using macros would also be really helpful when getting data from forms vie POST or GET. I tend to store all that data in temp variables, and it happens on pretty much every page of my website. So rather than writing very similar code on each page, I could just make a macro that does that for me and call it on every page. I could have a macro that just takes a hash, and stores all the data in properly scoped variables for the remainder of that page. I hope this idea ends up working because I don’t like to have a lot of scripting code on my content-pages (I believe they should be mostly HTML) and this would take like 5-10 lines off of those pages and move them somewhere else on the back-end.

Unfortunately, there are some problems with scheme. First off, it’s very hard to find a hosting company that’ll have a scheme interpreter for your use, so you won’t be able to use it for web scripting unless you build/maintain your own server(s). I also don’t know how (if at all possible) to interface with mysql, which could threaten the feasibility of the first idea. Finally it may not be easy to embed in HTML (a real plus for PHP), which may be a turn off to a lot of people. I don’t really know if the pro’s outweigh the cons with scheme, but I hope to play around with it and come a conclusion about it in the near future.

Scheme’s obviously a really cool language, but that fact that it doesn’t interface well with other things (mysql, html, other web stuff) gives me doubt to it’s usability. I was thinking that I could use it as a meta-back-end, making it spit out PHP code that I then evaluate at runtime, but this may not work out as planned if I can’t interface scheme with PHP. Even just by itself, scheme is really powerful and can do a lot, but as I’m trying to build a website, it’s not much use to me on it’s own. I’m gonna be spending the next couple of days trying to get scheme to interface with other stuff, and after that, I’ll have a better feeling for how useful scheme will actually be to me.

I’ve already briefly highlighted akrish.net’s structure in my previous post, but in this one I’d like to talk about some of the design strategies that I’ve used. Since I’ve already talked about how I read files, I’ll spend some time to briefly talk about how I’m writing into my xml files.

The first good design tactic I used was object oriented programming. So it’s really easy to use OOP in Java and some other languages, but in PHP it’s not the first thing that most people think about (at least I don’t). Yet it’s still really useful, because it allows you to compartmentalize all of your code into neat little objects that you can pass around and use really easily. So I have two classes: a Parser class and a Writer class. Both of them are for handling interactions between the web site and the xml documents that I’m using for feeds. The Parser object is pretty much what I explained in the previous post, except that it’s now an object. The Writer object has a function that writes a blog post into a specified xml feed, and that’s pretty much all it does right now. OOP is a lot better than functional programming in this case for a couple of reasons. First off, in the Parser object, all of the functions deal with an xml_parser object and so require an initialized xml_parser. This is easily solved by just iniitalizing one in the Parser constructor so that i’m only initializing the xml_parser once regardless of how many times I need to use it. Similarly parser functions need to know what feed to parse, but with OOP I can specify the feed in the constructor, rather than individually in each function. It prevents a lot of repetitive code. Another reason is that I can serialize objects and maintain all of their data as the user moves from page to page. I haven’t taken advantage of this yet, but I’ll need to it to allow a blogger to preview his/her new blog post. Anyway using objects makes the code a lot easier to read/change.

I also made the site highly modularized and functional. In addition to the objects, I also have a lot of functions that spit out content onto the pages. For example I have helper functions that spit out the html for the header, footer, and the navigation bars for all of the pages. These are really helpful, because I only have to make changes in one place, and the changes are propagated to the entire site. Furthermore, there’s a lot less code and a lot of my files end up having very little code, making everything easier for me to read later on.

I’ve also made change to how I show each feed, after realizing that I’d made a huge mistake. I used to have a separate file to show each feed (not the parser object, but each of these files calls the parser object and shows the content of the feed). This turned out to be a huge mistake because each of these files were the same except for which file name they passed to the parser. Anyway making changes got to be really tedious, because I’d have to make the same change on each of the files. I fixed this by making my index.php display all of the feeds. It selects a feed based on a parameter sent by HTTP GET. This is a lot better design wise for reasons that I’ve already mentioned.

Finally, the writer object is pretty straightforward. I set up an HTML form that’s password protected, with fields for feed, title, and body of the post. When I submit the form, I pass all of these parameters into the Writer. The Writer uses some simple regex’s to split up the text and add the proper xml tags. It then reads the old feed, and inserts the new xml into the old feed in the right place. Finally it re-writes the entire feed. I don’t think this is ultimately the best way to do it, because a lot of stuff stays the same in the file, and if the feeds get really long (which they may), this process may end up taking a while. For now it’s ok but I’m going to think about a better way to write xml files.

So that’s pretty much how this site is written. I do plan to add support for more tags, for example Image tags and Code tags so that I can style code differently will probably be added eventually. I don’t expect the rest of the back-end to change much so this’ll probably the last big post about akrish in here. Most of the other posts will probably be about wenote or any other ideas that I decide to execute. If you have any feedback about my design or if you’d like to see some features added, please let my know by commenting or by Thanks.