Showing posts with label web development. Show all posts
Showing posts with label web development. Show all posts

Thursday, January 5, 2012

Putting Two and Two Together (part 2)

Continuing from where I left off (and some of you guys are already ahead of me, maybe seeing what I'm about to put in here next) leads me into the introduction of CSS3 Buttons. The CSS3 Button has the text over the button, and it is not an image. The text on this button can be searched for, and the button can be modified, and scaled to your desires based on the generator. I just did a quick Google search for a few CSS3 Button generators, and I came up with quite a few results. You can use these generators to generate the raw code for these unique, yet powerful buttons to help reduce the strain of bandwidth to the users accessing your website, and to boost your website in a search engine's results.

Here is what you do: You locate one of these websites by performing a simple search. From there, you can design the button. You can alter the text, give it a shadow, make it glassy, make the button larger, etc. These tools make it incredibly easy to design some very high speed buttons to give your website the flashy, and upbeat appearance that you'll want.

After you design your button, you will be given two different segments of code. One will be for adding the object of a button to your webpage in the form of HTML source, the other will be the styling for the button. You can put the styling either in a main.css file, or in the specific page itself. What's great about the styles is if you have a list of buttons, you can use the same styling code and apply it to all of the buttons. These websites are very straight forward, and very easy to use for the average (or even newbie) web-developer.

Stay tuned for part 3, when I introduce the Color Scheme Designer.

Tuesday, January 3, 2012

Putting Two and Two Together (part 1)

Hey, guys. I'd just like to give you all a brief tutorial on making some awesome buttons for your website, but first, lets go over a little bit of background.

Here are a few things to keep in mind when doing this:
1) Keep images to a minimum.
2) Use text on your website.
3) Avoid image maps.

Keeping images to a minimum helps clean up your website, giving it a more tidy appearance. Using CSS buttons instead of images actually helps load time. If you go into paint to make a button, a small JPEG file needs to be rendered on the screen, where you could have one line of code to say "background: #000;" instead. When you break down the load time of your website, you want it to run as efficiently as possible. I've been in locations trying to look for things on my phone, and the 3G sucked. It took forever for certain websites to load up, so you'll have to keep in mind that not everyone is running on high speed.

Using text on your website optimizes it for search engines. If you have a really cool image instead of a cool CSS button, then chances are it won't be found as often. It's better to have both. The image for its appeal, and the text and tags for it to be found by search engines.

Image maps are great, but they're getting outdated... An image map allows you to take one image, and partition it, or split it into separate links. This is a great shortcut. Instead of using two separate images, you can use one... But will that really optimize your website? Image maps aren't the best for search engines either. There are some times where you must use an image map, but if you can go without it, try to.

Stay tuned for part two!

Friday, December 30, 2011

A New Way to Prevent SQL Injection

So, I had this idea as a way of preventing SQL injection on my websites for people who have to fill out text boxes similar to what I am doing now, and was wondering if I could get some possible feedback on the subject. I would take ANY and ALL data from the user, no matter what they want to type, and have a phphash file that would hash the entire text box into a massive string of numbers. Those numbers would then be stored either in the database, or in a specific file type, and when the data is retrieved, the numbers would then be converted back into text.

On the positive side, this would allow me to store string literals, and I mean LITERAL, which would be displayed where ever I want it to be displayed, and would run at a BigO of n.

On the down side, this may take up a lot of server-side processing speed dependent on how much information is being relayed back to the user, how many users are currently using the database, and how large of strings we're talking.

Essentially, this can be a fool-proof way (if implemented on every field) for storing string literals without the chance of an SQL injection attack. Meaning, someone could successfully write this post and append;DROP TABLE Users;-- without repercussion.