Jump to content

php_penguin

Privileged
  • Content count

    1,442
  • Joined

  • Last visited

About php_penguin

  • Rank
    richthegeek
  • Birthday 02/21/1989

Users Experience

  • Experience
    Web Guru
  • Area of Expertise
    Coder

Profile Information

  • Gender
    Male
  • Location
    Manchester, GB

Contact Methods

  • Skype
    richltl
  1. Codeigniter - a guide

    (I'll build this tutorial up over time) I've recommended it a few times before now and felt this deserved it's own topic rather than a reply to ayoungh's topic (amongst others). I've been using CI for about 2 years now, and have made plenty of commercial systems using it, as well as loads of personal projects. For this tutorial, I'll go through how I made the first half of my most recent personal project (nvoice.co.uk). I might avoid certain topics or glaze over them, so if you're confused just let me know. My MSN/Skype is listed in my profile so if you have questions, ask me there or on here. Part 1: Installation & configuration Installation First thing you want to do is download CI from the website (http://www.codeigniter.com), currently at version 1.73, and unzip it into a folder in your webroot. That's it - CI is now installed! For this tutorial, the folder is /var/www/nvoice/ (or C:/Apache2/httproot/nvoice/) From now on, this folder will be shown to as "~", eg "~/system/application/controllers". Configuration There are *tons* of config options for CI, but most are thankfully optional. A few, however, are very much not, and you need to set them correctly before you start work. All config files live in ~/system/application/config, and are well-named. Here's a run down of the important config files: autoload.php - Defines which files are automatically loaded, and is very useful. You *will* be auto-loading libraries, models and helpers. config.php - The most important file - defines your BASE_URL, INDEX_PAGE, and a few other bits and pieces. database.php - Your database connection info. hooks.php - If you are using hooks, you'll be using this file. routes.php - Routes are very handy, and they are defined in here. To set up a system, you need to define your config:BASE_URL and database settings at the minimum. You will also probably add some helpers to your autoload list, enable config:GLOBAL_XSS_FILTERING and change your routes file. (more on routes later) So, set your base url to "http://localhost/nvoice/", your database settings appropriately, and add the following autoload settings: Libraries: database, session Helpers: url, html, cookie Part 2: System components - what are models, controllers, views, libraries, and helpers? This is by far the most commonly misunderstood component of CI at first, and probably also the most asked question on the forums. Here's a very quick explanation of each type... but frankly, clarification best comes from creating stuff with the system and no words I can write will give you ultimate truth in this matter. Models: Classes designed to interact with a database table (or database view) directly, providing useful functions to be used by controllers or other models. Generally these follow a CRUD pattern. Controllers: The beating heart of your system - these get loaded based on the (routed) URL and basically control what your system will do on each page. Generally, each function should be no more than 10 lines long and contain almost no logic. Any more than that and you need to rethink what you are doing. Views: These are where ALL your HTML goes, split into relative templates and parts of templates, for example a separate view for header and footer. Generally, these should contain no logic beyond simple loops and if statements. Libraries: These are classes similar to a Model, but typically work on things other than the database, or as an amalgamation/extension of two or more Models. An example would be a templating library, or a library for handling image editing or manipulation. Helpers: Groups of functions related to each other, but which do not require a shared memory space (in which case you'd use a library). --tbf--
  2. How to be a better programmer

    updated
  3. How to be a better programmer

  4. How to be a better programmer

    That was my code XD
  5. How to be a better programmer

    Giving an accurate estimate means you (shouldn't) be trying to cram the code-writing into less time than it deserves. Not being rushed leads to better code - efficiency isn't just volume/time; quality affects this measure. This is different to most other businesses - with design it's a boolean subjective good/bad, other businesses it's either done/unfinished. Programming can be completed poorly whilst still meeting the spec, and this will affect customer satisfaction and your reputation, so estimating is a vitally important skill to master more-so in this industry than others. Similarly, making sure your payment is guaranteed means you won't spend your time worrying or confirming it. Regardless, if you feel you can contribute something more "worthy" please do
  6. How to be a better programmer

    Those parts are all applicable - being a programmer isn't *just* writing code. Feel free to add your own bits of advice!
  7. How to be a better programmer

    Alternative title: "advice I wish I had been given at the start of this job, based on my experience as a web developer but probably applies to other professions (except I didn't want to be so obnoxious as to expect they all did)" What follows is a list of rules of thumb that I find myself following (and not following where required), general bits of knowledge, etc. Please reply with rules of your own! It doesn't matter what you use (within reason) - so long as you use it well Time and again I see topics on forums asking "what text editor/IDE/OS/browser should I use?" - and often the answer is different every single time. This is because the recommendations are based on what works for the person answering, and that is founded on only one thing: experience! Wether you choose between an IDE (Netbeans?) or plain text editor (notepad) or somewhere in between (notepad++, gedit) the only thing that you *must* do is fully understand the program, it's keyboard shortcuts and additional tools (snippets, code checking, class browser, code folding etc). When you truly know a program you will be able to rattle at your keyboard and lay your thoughts down as they occur, without *thinking* about how to move between pieces of code. That said, here's my choices (and why) Ubuntu 10.10 - free OS software that I can customise as much as I want, and have it such that I can do *all* window management tasks from the keyboard. gEdit text editor - default in Ubuntu, has the features I need but nothing more. Starts up instantly, snippets, external tools, syntax highlighting, compile-on-key. Firefox + Firebug - for any Javascript development, Firebug is verging on essential, simple as! Bash (gnome-terminal), GIMP, Docky (timer plugin!) [*]Know a little bit of everything. Know everything of a few things It is very rare that you will get a job requiring only one piece of knowledge (only jQuery, for example) and even worse, you'll be limiting your potential by seeking jobs like this. That's why it's best to know a small amount about all things, a good amount about things related to your chosen tool (HTML for jQuery + PHP, for example), and absolutely everything about one thing. The thing is, the knowledge in each of these areas complement each other and enhance your abilities in the primary choice... and your knowledge will increase in the secondary areas much quicker than expected.[*]In the words of Marcellus Wallace: "F*** Pride" Don't bother getting into this professionally if you will put your pride above all else. Sometimes you *will* have to take jobs that you find boring, annoying, or even a bit morally ambiguous. You can always turn these down... but sometimes these jobs lead to better jobs, or sometimes you just need to pay the rent.[*]How to estimate First thing to say when someone asks you to estimate? "I'll get back to you", or words to that effect. Unless the job will obviously only take an hour or two, give this answer. Anything else is dishonest. Now, to estimate a task you must make sure you have adequate data to provide an estimate. Don't be afraid to ask for more info - the clients will invariably prefer that you ask too much than not enough. To estimate, break down the task into smaller tasks. Repeat this recursively until no individual task takes more than half a day. Add up the number of tasks and multiply it by 1/2 for a minimum, and 1 for a maximum number of days. If we have 35 tasks to completion, it will take 18 to 35 days. Apply your own judgment! Now we have a number of days, we turn it into an appropriate figure. If it's less than 15 days, say it in days If it's less than 8 weeks, say it in weeks (there are 5 days in a week, not 7... 35 days = 7 weeks) If it's less than 30 weeks, say it in months If it's longer than that, the task is probably too large - try break into multiple deliverables.[*]Always get something signed (or use escrow) Until you can trust the person you are working with (repeat work, or a family friend) you must assume they are out to bite you in the ass. Always get a signature on a contract, or a confirmed amount in an escrow service. ALWAYS.[*]Backup, Backup, Backup Ideally this will be a regular SVN/GIT commit to a remote server, but if you can't do that, at least do an auto-tar+upload (rsync) to somewhere safe (external HDD and/or remote server).[*]Use a CLI (bash or cygwin) A Command-Line-Interface is an incredibly powerful tool for file search and manipulation, and you really should get over the initial fear caused by the complete lack of mouse-based interaction. For linux users just run a terminal and you're done (bind to ctrl+alt+t), for Windows users see Cygwin for (almost) identical features. Learn how to pipe between commands, how to use find, awk, sed, grep, and anything else you come across. Read the man page for everything (man command = user-guide for command)[*]Document everything Just because you're the only one working on a section of code or even a whole project, write comments on all your code. Whilst it does benefit other programmers, it's primary beneficiary is *you*. Writing comments before you write the code helps clarify what the code is meant to do, and writing it down in easy form means you can more easily see any logical inconsistencies.[*]Use a commenting microlanguage You can use a specific comment format which allows you to auto-generate documentation for all your classes and their methods. Javadoc, PHPDoc, and JSDoc all follow the same format, and there is a similar implementation for most languages.[*]What to comment? A difficult question to answer really, as it's best taught through experience.. for simple commands just comment what that "section" of commands will do - for complex stuff, or stuff that vastly changes the form of the data put a comment per line. Anything that strings multiple functions together should be commented. See sunwukung's comment more to follow
  8. Sidejacking, and how to stop it

    CodeIgniter is a free OS OOP HMVC framework (wooo acronyms) that prides itself on being: - lightweight (about 1.3mb memory footprint usually, which is good for it's capabilities), - extensible (true, but requires decent code skills), and - allowing minimal code to get things done (again true, again requiring good knowledge to truly exploit) It doesn't force a new microlanguage or meme on you like most frameworks, beyond gently nudging you towards following the MVC pattern. I strongly recommend you try it out for a few weeks - it's cut my code time (creation AND maintenance) dramatically whilst increasing program performance.
  9. Sidejacking, and how to stop it

    I'm a 3rd year Computer Science student, and have been using PHP since for about 6 years (since I was 15). I've been using CodeIgniter for around 2 years and have created plenty of commercial systems with it... so plenty of experience.
  10. Sidejacking, and how to stop it

    Common sense and experience are my tools - relying on the knowledge of others (either in pure form, or tool form) is also a good route. My latest login code (which I make no claims as to it's perfection) is as follows (in form of a CodeIgniter model, the best framework ever): function login( $username = false, $password = false ) { // get from object if not passed if( ! $username ) $username = $this->username; if( ! $password ) $password = $this->password; // create salt $salt = sha1( $username.$password.time() ); // update database based on username & password $this->db->where( "username", $username ); $this->db->where( "password", sha1( $password ) ); $this->db->set( "salt", sha1( $salt . $_SERVER['REMOTE_ADDR'] . $_SERVER['HTTP_USER_AGENT'] ) ); $this->db->update( "users" ); // the "it didnae work" bit if( ! $this->db->affected_rows() )return false; // if it did work, get the user from the db $this->db->where( "username", $username ); $this->db->where( "password", sha1( $password ) ); $user = $this->db->get( "users" )->row(); // backup "no database" failure bit if( $user->salt != sha1( $salt . $_SERVER['REMOTE_ADDR'] . $_SERVER['HTTP_USER_AGENT'] ) ) return false; // copy data to object foreach( $user as $i=>$v ) $this->$i = $v; $this->parse_settings(); // set cookie set_cookie( "natrium", $salt, 86400 * 30 ); return true; } function get() { // if user is already set, return self (true) if( $this->username && $this->id ) return $this; // unset all variables as backup foreach( array( "id", "username", "email", "password", "salt", "name" ) as $k ) $this->$k = false; $this->salt = get_cookie( "natrium" ); // get user from db where salt matches rehash $this->db->where( "salt", sha1( $this->salt . $_SERVER['REMOTE_ADDR'] . $_SERVER['HTTP_USER_AGENT'] ) ); $q = $this->db->get( "users" ); if( ! $q->num_rows ) return false; foreach( $q->row() as $k=>$v ) $this->$k = $v; $this->parse_settings(); return $this; } btw: natrium is the Latin for sodium, one half of table salt (sodium chloride) and most other salts...
  11. Sidejacking, and how to stop it

    Indeed it is worth saying, and said it was in the original post.
  12. Sidejacking, and how to stop it

    I posted this on my Facebook for my CompSci friends to see, figured it'd be helpful outside of those 50 or so people. "Sidejacking" is when a hacker uses a packet-sniffer to detect the login auth cookie and uses that cookie data himself to pretend to be authorised on a website. This is possible because mostly what we do to say that a user is authorised is create a unique hash (using sha1 or similar) and store it in both the database and the cookie: salt = sha1( username + password + time() ) cookie['login'] = salt database.write( login = salt ) Then to check that the user is authorised, we do if( database.get_where( login = cookie['login'] ) ) ... Sidejacking works because the cookie can be used from any location. How to stop this? Add some user-specific data (IP and user agent) based encryption and store two different hashes like so: salt = sha1( username + password + time() ) cookie['login'] = salt database.write( login = sha1( salt + IP + UA ) ) if( database.get_where( login = sha1( cookie['login'] + IP + UA ) ) ... Now a sidejacking attempt can't work because the IP and UA is required to transmute from the cookie salt to the DB salt. Simples Note that this won't stop all attacks - the UA is not unique to each user and sidejacking often occurs within the same network (so the IP is shared beyond the router), but it will stop most of the rudimentary attempts when you can't get SSL running throughout the site. (The easiest and most complete method of stopping sidejacking is using SSL (https) encryption for all authorised pages so that cookies/sessions can't be grabbed by a packet sniffer. However, that's not always a possibility due to server or cost restraints.)
  13. General design and shopping cart

    Thanks for the reply. Font is pretty limited really, unless I can be bothered with SIFR. The main pages have a 4-column product listing, or a single product page so the focal point is fairly well defined with the initial pages. Once the user is at the cart stage, they should know well enough what to be looking at, and a checkout doesn't really have to "pop"
  14. acatalog

    The acatalog folder is related to Actinic Catalog ecommerce software - he should have the program installed on one of his machines, along with the original MSSQL/Accesss database file. It will already be configured to upload to the correct server, so there is not really a need to back it up.
×