"...original item for "Shares" cannot be found." when sharing PC to Mac

I tried to share an external drive from my WinXP box to a Mac (MBP) and always got the following error:

"The operation cannot be completed because the original item for "Shares" cannot be found."

Searches on Google came up with plenty of solutions for this error, but none of which worked in my case.  So in case it helps somebody in the future, here's how I resolved it.

A little investigation revealed that I could share other folders and access them fine from the MBP, just not the external drive.  I eventually figured out that I just couldn't share things that were large.  Since my external drive was 500 GB, it easily fell into this category.

This size restraint on sharing was fixed by following instructions here:

http://support.microsoft.com/kb/106167

Basically, there's some parameter (on the WinXP machine) you have to adjust to allow larger things to be shared.  The parameter is adjusted/added using regedit.  I changed it to the max value of 0xC (12), and that worked fine.

Use of PHP functions within Smarty code

Can standard PHP functions be used directly within Smarty code?  The answer is yes, but the proper syntax depends on where you use it!  For example, the syntax is different for 'assign' statements than for conditional statements.  See the examples below for getting a count from an array variable named 'aArray'.

Assignment syntax:

[{assign var="iCnt" value=$aArray|@count }]

Condition statement:

[{if count($aArray) == 0 }]DO WHATEVER[{/if}]

So in the case of assignments, a variable modifier must be used.  But within condition statements the function can be called directly.

Old Photo Effect With A Touch Of Colour

Here's the result of trying to simulate and old photo feel, but with some added colour. I used the following photo as a basis for what old looks like.

Taking note of the following characteristics:

• Blurred edges
• Grainy print
• Stained edges

I went ahead and shopped the following:

• Used Artistic > Film Grain filter
• Gaussian blur masked by a radial gradient with the start of the gradient offset by 50%
• Black & White adjustment layer with tint, and manually adjusted to best bring out pattern of shirt in photo.
• Added mask to B&W adjustment layer and used grey to to partially expose some original colors.
• Slightly reduced opacity of B&W layer to give a little overall color.
• Added a radial gradient to the border with a tan colour and gave it Multiply blend mode.

Result is shown below.  Overall I'm pretty happy with it.  However, I wish I could have reproduced the randomness of the stained border in the true old photo, rather than just using a radial gradient.

BEFORE:

 

AFTER:

PayPal Website Payments Standard vs PayPal Express Checkout

Just a quick explanation of the difference between the PayPal services Website Payments Standard and PayPal Express Checkout and why you would choose one versus the other. I've found myself asking this question more than once now, so next time I can just recall what I wrote here.

Website Payments Standard is a completely FREE* PayPal service that can process credit cards without requiring a PayPal user account. The disadvantage is that all processing takes place off-site. That is, the integration with the retail site is limited to just re-directing the user to PayPal for checkout. After this happens, there's no guarantee the user will ever return to your site which makes having a consistent confirmation page impossible. But beggars can't be choosers and this service is, after all, free.

Express Checkout is also FREE* and offers better integration with your site. It works by directing users to the PayPal site just to enter payment info, and then returning to the retail site to complete the order. All in all this seems like a better solution, allowing complete control over the final stages of checkout, including payment processing and confirmation. Additionally, recurring payments (a.k.a. billing agreements) can also be setup and even combined with regular one-time purchases. The down side is that the API programming is more complex and the amount of user interaction required to complete an order can increase (a possible negative impact on conversion rates). But if you're comfortable with the free API (PayPal NVP) then I'd say the benefits far outweigh the disadvantages. Note that PayPal also offers a SOAP interface, but I believe use of this requires a paid account.

Either way, if you choose to integrate a FREE* PayPal service expect many headaches on the way. My experience with PayPal places it as #1 in the Worst Software Integration Experiences. Their developer/sandbox tools are more flare than function, their documentation is selective or just out-of-date (not sure which, but probably both), and their technical support is utterly useless. But what alternative do we have? For smaller volumes of sales, it's still (by-far) the cheapest credit card processing service on the planet. Have fun!

*NOTE: The word FREE here refers to no monthly service charges. All merchant gateways charge transaction fees with PayPal on the high-end.

Customize Terminal for Mac OS X Snow Leopard

Wanted to permanently change the default prompt used in the Mac Terminal as well as add other customizations to Terminal behaviour. Found mixed recommendations on the web for how to do this, but none of which worked for me on a MBP with OS X 10.6. In the end I just guessed at a few things at eventually did the following:

- Edit the file /etc/bashrc (that's right, not '.bashrc' but simply 'bashrc').
- Append the desired value for $PS1, which overrides the definition already present in the file.

For example, to customize my prompt and have all 'ls' commands become 'ls -al' I appended the following:

PS1='\u: \w\$ '
alias "ls"="ls -al"

Notes on Installing Lighty (lightTPD) + PHP on Mac OS X

Although, in general, a relatively easy process when done as described here, it still wasn't w/o issues for me. The two main articles I based the install off of are as follows:

1. Install PHP5, lighttpd and Imagick on Mac OS X Leopard
2. Symfony flying with Lighttpd on Mac OS X 10.6

In my case I was using Snow Leopard (10.6) and didn't care about Imagick or Symfony so simply ignored those parts. My system is also already a running MAMP (Mac+Apache+Mysql+Php) so in the end I configure Lighty to run on port 81 and, for the sake of this blog, I'm not bothered with installing MySQL because I already have it. If you need to install MySQL, however, there's now a self-installing package for Mac OS X so it should be a breeze.

I found the following useful for if things go wrong:

- Check if lighttpd was loaded AND enabled using the terminal command "sudo launchctl list".
- Open up the ever-handy Console utility (Applications>Utilities>Console) and view the Console Message or system.log. If Lighty is trying to start but failing it should show a message about every 10 seconds explaining why it failed.

INSTALLING LIGHTY

In my case, the main reason the default installation didn't work is because of the following default Lighty configuration:

server.network-backend = "linux-sendfile"

Which results in the following error: "server.network-backend has a unknown value: linux-sendfile"

Not sure what the 'best' value should be on a Mac, but simply changing this to:

server.network-backend = "writev"

worked for me.

I also tripped on the following, so watch out! The modules.conf file says "at least mod_access and mod_accesslog should be loaded" and then the server.modules variable shows only "mod_access" by default. So I added "mod_accesslog" but this only stopped Lighty from loading. So don't do this! Later realized that the accesslog module is already included in the master lighttpd.conf file.

Also, you do NOT need to add modules to the server.modules variable if there's already a predefined .conf file in the conf.d directory. Simply un-comment the line in modules.conf that includes the appropriate file. This is because the include file does this for you.

INSTALLING PHP

Again, mostly just followed the instructions. Below are things that varied for my install or selections I made when instructions differed.

1. The install command in the Imagick instructions is out-dated and will not install MySQL. The command in the 'Symfony' instructions look more up-to-date but still didn't work for me. I had to instal several extensions separately. The commands I used were

"sudo port install php5 +fastcgi +pear"
"sudo port install php5-mysql"
"sudo port install php5-xsl"
"sudo port install php5-gd"
"sudo port install php5-mbstring"
"sudo port install php5-iconv"
"sudo port install php5-curl"
"sudo port install php5-openssl"
"sudo port install php5-soap"

Installation of php5-mysql output the message "To use mysqlnd with a local MySQL server, edit /opt/local/etc/php5/php.ini and set mysql.default_socket, mysqli.default_socket and pdo_mysql.default_socket to /opt/local/var/run/mysql5/mysqld.sock" but I just ignored this (tried doing it, as well as making the appropriate directory with group permission for mysql user, but then Lighty connections to MySQL started failing).

2. Config files were located at /opt/local/etc/php5 and I copied from the dev default file since that's what I'll be using Lighty for.

3. Didn't bother with changing the extension_dir variable.

4. My install came with a hierarchical .conf file structure so enabling PHP involved multiple .conf files as opposed to a single lighttpd.conf file. This involved...
- un-comment the line "include "conf.d/fastcgi.conf" in modules.conf
- adding the following to the end of the fastcgi.conf file:

fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => socket_dir + "/php-fastcgi.socket",
"bin-path" => "/opt/local/bin/php-cgi"
)
)
)

- Note that the socket directory uses a pre-defined variable, unlike the fixed
paths given in the referenced instructions.

5. Setup ownerships and permission mostly according to the 'Symfony' instructions, but my paths were based on variables defined in lighttpd.conf. For example, the pid file path was
server.pid-file = state_dir + "/lighttpd.pid",
which was equivalent to
"/opt/local/var/run/lighttpd/lighttpd.pid".
As a result, the folders and location of files I needed to give www ownership to varied from those in the 'Symfony' instructions.

6. Note that my install had no lighttpd.wrapper file, so they start/restart command were not applicable. I had to start/restart using load/unload with the launchctl command. For example:
"sudo launchctl load /opt/local/etc/LaunchDaemons/org.macports.lighttpd/org.macports.lighttpd.plist"

ADDING VHOSTS
For this I used the simple_vhost module.

1. Un-comment the following line in modules.conf

include "conf.d/simple_vhost.conf"

2. Edit simple_vhosts.conf accordingly. For example,

simple-vhost.server-root = vhosts_dir + "/"
simple-vhost.default-host = "lighty.anotherlocalhost"
simple-vhost.document-root = "/anotherlocalhost/"

In this example above, the path

vhosts_dir + "/lighty.anotherlocalhost/anotherlocalhost/"

MUST exist. That is, the path to the doc-root includes a directory named after the default-host variable.

3. Add an entry for lighty.anotherlocalhost into you hosts file (/etc/hosts) and clear the cache for this (terminal command: "dscacheutil -flushcache").

Handling Upfront Payments with FrontAccounting

Maybe it's just because I'm new to all this accounting stuff, but I didn't find the method of logging upfront payments in FrontAcounting very intuitive. Maybe it's similar for all accounting software but, in anycase, here's how I worked it out.

This applies to sales with an upfront (aka, prepaid, on demand, paid in advance) payment method. For example, you receive a payment online via PayPal which goes directly into your PayPal account, and then you process the order accordingly with no further invoicing required. I found that there are 2 different ways to handle this in FA which I will refer to as the Traditional Method and the Quick Method. I call the longer method traditional because it was once the only option before FA added 'Direct' invoicing.

TRADITIONAL METHOD:

PRE-REQ: By default, FrontAccounting does not create a prepayment payment option so, if not already done, you must do this manually. Under Setup>Payment Terms, create a new payment option of Payment type 'Prepayment'. For example, create one named PayPal.

[1b]
When order is received create an applicable sales order (Sales>Sales Order Entry) and select the desired prepayment option (that you should have created), such as PayPal, for the Payment field.

[2]
Once the order has been processed/shipped create the Delivery Note & Sales Invoice by first using Sales>Delivery Against Sales Orders and selecting the sales order in step 1, then using Sales>Invoice Against Sales Delivery and again select the same sales order. This step will generate the appropriate Delivery Note and Sales Invoice entries in the journal. The Delivery Note handles inventory transactions while the Sales Invoice debits the Accounts Receivables for the order amount. Optionally, you can combine steps 1b & 2 using Sales>Direct Invoice.

[3]
Add payment using Sales>Customer Payments and select the sales order created in step 1 (note that sales order will only show here if it was created with a pre-pay payment type). Also remember to select the appropriate receiving bank account (such as PayPal). If applicable, as is the case with PayPal, include the transaction fee in the Bank Charge field*. This step creates a Customer Payment entry in the journal which essentially transfers Accounts Receivables (as created by the previous step) to an actual bank account.

For cases where some or all of the revenue received from the sale can be reported prior to shipping, the additional steps below can be added to the process. Note, however, that according to accounting rules revenue from retail sales must, in most cases, be reported only once the product has shipped.

Add this step before 1b:
[1a]
Make a customer payment (Sales>Customer Payments) for the amount that is to be received as income prior to completing the order.

Add this step after 3, although step 3 may no longer be necessary if revenue received prior to sales order was the complete amount:
[4]
Now assign the Sales Invoice to the Customer Payment using Sales>Allocate Customer Payments or Credit Notes. There you should see the Customer Payment you created in step 1 which, after you select the allocate icon, you can assign to the Sales Invoice created in step 2.

*NOTE: Bank charges by default go to the Interest & Bank Charges account. If you'd like to track PayPal fees to a different account you can create one and assign it as the Bank Charges Account under Setup>System and General GL Setup. However, because this option is not bank specific ALL customer/supplier payment charges will now go to this account. If you only use PayPal for payments that involve charges, this is OK, otherwise you'll have to live with all charges being clumped together into the default account.

QUICK METHOD:

The much (much much) quicker method involves just a single FA form but you cannot control the date of journal entries (all entries occur at once), you cannot enter an optional bank charge, and the order amount must be paid in full in one shot.

PRE-REQ: You must create your PayPal account as a Cash Account and you must relate this account to Point of Sale (POS) transactions under Setup>Points of Sale as well as under Setup>User Accounts Setup>User's POS.

[1]
Create a Direct Invoice (Sales>Direct Invoice) and select the "Cash Only" Payment type. If you configured POS correctly (see PRE-REQs above) the PayPal cash account should be the Cash Account under the Cash Payment section. Place the invoice and that's it! This will automatically create the Delivery Note, Sales Invoice, and Customer Payment journal entries which ultimately puts money directly into you bank account. For more details on what these journal entries do refer to the Traditional Method.