Tag Archives: PHP

Utilites

ownCloud – a self hosted alternative to DropBox and Google Drive

Leave a comment

I’ve used both DropBox an Google Drive for a while. They are wonderful. I’m going to talk for a moment about free self-hosted alternative that I’ve grown fond of.

2019 UPDATE: I now recommend NextCloud. It’s the same, just a different name.

Features Overview

  • Nice iOS app.
  • Mac & Windows clients are better than Dropbox
  • Support for multiple sync locations and selective sync
  • Public link sharing with optional password or expiration.
  • Server requires just PHP

Sharing

Sharing works very similar to dropbox. The expiration date & password options are quite nice for limiting who has access and for how long.

Selective Sync

Like Dropbox it supports selective sync.

Bandwidth Limiting

Great for control if you’re syncing large files. The Automatic setting is quite handy

Coding

Remove public directory for laravel

Leave a comment

To get rid of the /public you can either:
A) Upload vender, bootstrap, and app folders on directory higher than the htdocs or www folder. Then place all files in the public folder to the into htdocs or www.

B) Move files in public directory one folder higher, modify index.php removing the up directory “../” from the includes.

C) Make an .htaccess file in the root something to the effect of

RewriteEngine On

RewriteRule ^(.*)$ public/$1 [L]

Coding

Code: Laravel Scope Query on a Model

Leave a comment

Let’s talk a bit about scoped queries in Laravel. First here is a basic Book Eloquent Model with two handy scopes for type and fewerPagesThan.

//Book Model
class Book extends Eloquent {
public function scopeType( $query, $type ) {
return $query->where( 'books.type', '=', $type );
}

public function scopeFewerPagesThan( $query, $pages ) {
return $query->where( 'books.pages', '<=', $pages ); } }

Using scoping

I often see confusion when we try to use scoping. Some would expect the following to give them back all 'autobiography' books:


Book::type('autobiography'); // This works right? Nope!

But it doesn't. Scoping functions will only refine your query. For instance all the following are great examples of using scoping:


Book::type('autobiography')->get();
Book::with('author')->type('autobiography')->get();
Book::fewerPagesThan(500)->type('autobiography')->get();

Building up scopes

When using scopes to refine and filter down which Models to retrieve, you will always need to add a ->get() at the end. This allows you can chain multiple "scopes" onto each other as in the 3rd example. Basically it needs to know when you are done filtering down and when to actually hit the database.

So the 3rd example could be broken down like this to really drive home the point:


$maxPages = 500;

$books = new Book();
$books->type('autobiography');
if( $maxPages )
$books->fewerPagesThan($maxPages);
$opportunities->get();

In every case before the ->get() call $books var is a Eloquent/Builder that is being built up.

After the ->get() call $books var gets overwritten with an Eloquent/Collection that has been filled with our data from the database.

This is a very powerful and flexible to way to scope and filter down models that are in your database. It is better to filter them down with scopes in the DB query than filter down a collection that has already been loaded into memory. Make the your DB do some weight lifting for you. 😉

Coding

Code: Getting multiple specific Laravel models

Leave a comment

I had a case where I had an array of model ids, and I wanted to return a collection of these models. That is I had a list of model ids, but it appeared no nice way to get all of them at once. However from the 4.2 API docs you can see that the find() should be able to return either a Model, or a Collection of models.

Find()

Naturally to get one model just use:
User::find( $id );
You could loop over the ::find() to pull each one manually, but that will result in multiple unnecessary queries to the database right? Who wants that?

Find() with Array

Here is a quite simple approach that Eloquent supports that seems quite obvious after you see it. You can just pass an array of model ids right to the find() function!

$arr = array($id1, $id2, $id3);
User::find( $arr );

This will return a collection of models just as you would expect, no fussing around with loops.  A simple way to get Multiple Specific Laravel Models by Id.

Coding

Case Study: Unique Serial

3 Comments

I did some work repairing a gift certificate for NowStudio.co that a previous coder had created. The certificate is quite fantastic and keeps track of purchased certificates in a database. However, much of the code was written for PHP4 and had logic bugs that needed to cleaned up. A nice fun side project to work on.

The Problem.

The original coder used PHP’s rand() function to generate a number between 10,000,000 and 99,999,999 for the serial + the purchaser’s full name.

Not Unique. The obvious reasoning being that they didn’t want someone to be able to guess a certificate number and redeem a previously payed for certificate. Makes sense. However, there is a key flaw with creating serials this way. Random != Unique. There is the off chance, given time, that two certificates will be created with the same serial!

Using Names. The original coder recognized there was a chance a duplicate serial could be picked. They decided to use both the serial and the the buyer’s first and last name as the unique entries. Excellent idea and certainly seems to solve the problem. However, names tend to be unpredictable and unreliable. For instance, some last names are multi-part (Elfriede Von Kosh), have punctuation (Patrick O’Conner), or contain diacritic marks (Soňa Novak) among other things. This can cause unreliability with the app.

The question.

How can I create a better method of serializing the certificates?

Here are some requirements I came up with:

  • It has to be unique
  • Cannot be re-used
  • Non-continuous
  • Not guessable
  • Shouldn’t need to query the database to verify the serial hasn’t been used
  • Meaningful
  • Manageable in length

The Solution.

I decided simple solution is to use the full date/time + 4 random digits. For example this moment would be 2013-02-17 at 17:11:32 + 8345  or in string format  201302171711328345.

The Date. This serial has the benefit of telling us the exact moment it was generated. I use a 24-hour clock keep the length of the string always the same as well as to avoid the accidental repeated digit twice a day (9am and 9pm), that would be quite awkward. It would only increases the odds of getting a duplicated serial.

The +4 Digits. Using just the date and time down to the second I was still bugged that in theory two users could land on the page at the same moment and be served up the same serial. That’s why I felt the necessity to add the +4 random digits to the end of the string. While in theory it may be possible to still to generate duplicate serials, this makes it rather unlikely. During the save to the database we can always do a double check if we feel it is needed.

The Code.

For the landlubbers that want to use use this method of creating a serial, but don’t want to write it themselves – Here is what it looks like in PHP:

$serial=date("YmjGis").rand(1000,9999);

Too simple? Know a better solution? This only would work for small-medium sites.