I’ve set up my VirtualBox to access my localhost (OSX) by following instructions similar to this post, using NAT. Everything was great until I started testing the staging site on the net (not my localhost). Most things worked fine, but uploading larger images would just fail in IE. Uploads worked fine on the localhost, but failed on stage, so I initially thought it was a configuration on the staging server webserver.
Solution
The problem was the network adapter for VirtualBox. I was using NAT as the network adapter setting. This was the cause of the issue.
My VirtualBox was not receiving the ICMP Fragmentation Required bit from the server. That is why larger images would hang, but smaller images would go through fine.
Now the solution is to change the network adapter back and forth between NAT and Bridged when I notice funkiness on remote sites.
This essentially uses different files to open new windows, it’s managable to point, but I had trouble with not having some sort of global variables I could call on.
These keep the entirety of the code in basically a namespaced object. I have to admit, it took me 2-3 times looking over the code to really get it. Let me try to help.
app.js
This is the app.js file
We are including the main include file. As you’ll see, files add new methods and properties to the global object, then include other sub files that will add more properties and methods.
tt.ui.createApplicationWindow() creates a Titanium window and is passed to the tt.app.mainWindow property. Then it’s opened with open()
/tweetanium/tweetanium.js
This is the /tweetanium/tweetanium.js file. The initial file in our application.
Here we are creating the namespace tt, all properties and methods will extend this object.
This is an anonymous self executing function that holds some initial methods. tt.app is used to hold various properties such as currentWindow.
Lastly we include sub files. Notice how the subfiles are named like their folders. So you have /tweetanium/ui/ui.js and /tweetanium/model/model.js. You could name them anything, but in those respective files they include all the files in that folder, let’s take a look.
/tweetanium/ui/ui.js
Here we are in the /tweetanium/ui/ui.js file.
We now create a subobject called tt.ui that will hold all the user interface properties and methods. Then we can add any utilities used by various interface functions
Now we include all the user interface files. There are some that are Views, and others that are Windows. So if you have a View shared by several Windows, you can split that out into it’s own file. Notice that we include all the rest of the files in that ui directory.
There you go
Using this same waterfall approach to building the namespace, you can make the whole Titanium app in a surprisingly short amount of time. Once you get structure to your files, it’s easier to stay organized.
Some further files to investigate would be the /tweetanium/ui/styles.js and the /tweetanium/ui/ApplicationWindow, noticing that most windows have a corresponding create**** method that will create the object and had it back to the caller.
I would get random error messages from my MongoDB based app GoScouter of
couldn't send query
It was random and quite frustration. I was not able to find anything definite online about such error, but that it might be a bug in the PHP MongoDB Driver. I was using version 1.2.7, so I did a pecl upgrade mongo on the web server (using PHP-FPM) and this seemed to fix the problem. Now I’m running version 1.2.9 and I have not received a Couldn't Send Query error yet.
So looking through the Doctrine ODM docs on Query Building, I didn’t see anything that lent itself to a like query such as that is found in MySQL. There isn’t a like, option, but using Regular Expressions will work just fine for me.
I’ve been stressing using PHPunit more and more in my projects and endevour to include tests for all my classes. When you are connected to a DB, it’s harder to test, but with the help of the Doctrine2 workflow, I think I’ve found a nice way to keep DB updates out of my Unit Tests.
How to test without touching a DB?
First, you need to have really skinny controllers. What does that mean? Well, controllers should really only do a few things.
Work with both the Request and the Response
Instantiate forms and populate them with data
Talk to the Views
Hand everything else off to a class in the services directory
Did you catch that last part? Most of the heavy lifting you’re tempted to put in the controller should be shifted out to a services class (e.g. Application_Service_Email). That way you can keep your controllers nice and lean.
Now the services classes will be the ones doing instantiating classes to get the work done.
How does Doctrine fit into this?
Glad you asked. Doctrine uses a particular workflow when writing out values to the DB (MySql, Mongo, Postgres).
First you have to tell Doctrine to persist your object, in our case here the $user object. This is done using the DocumentManager ($dm). How do you get ahold of $dm? That’s another lesson soon to come.
$dm->persist($user);
You can do this to multiple objects and Doctrine keeps them in a queue. Then you have to write your changes to the DB. We do this with the flush command
$dm->flush();
That physically goes out to the DB and creates/updates/deletes all the objects in the queue. A very efficient way to work with the DB.
That’s great, but how does this fit into Unit Testing?
Simple. We persist in the Service class and flush in the controller. Here’s how this would look in the code? I thought you’d never ask.
The important parts to look at in the above code is the in the ‘User.php’ (Service Class), we are persisting our objects there. In the Controller we are flushing them.
This makes it easy to test since you’re not actually going to hit the DB unless you test the Controller (That’s integration testing, not Unit testing).
One Caveat
Sometimes you need the Id of an object. You’re only able to get this when you actually insert the object into the DB. So in your Service class it may be necessary to issue the flush command, but there are ways around this tool.
I had just set up a Poedit for a project at work and was trying to update the *.po file with new translations. It wasn’t finding a whole load of them.
After a while of poking around, it dawned on me that it was not looking in my phtml files. Simple enough, I just added *.phtml to the list of extensions in the parsers preference.
Then I receive a big long error message that xgettext didn’t know what phtml.
Solution
Add pthtml to your list of extensions
*.php;*.phtml
You also need to add ” -L php” to the end of your Parser command
xgettext --force-po -o %o %C %K %F -L php
Should you upgrade to OS X Lion??? Meh…. it’s presented more problems than previous upgrades.
Maybe I should have waited until 10.7.1, so this is my punishment for being bleeding edge.
Another issue I saw was the continual nag when I opened some apps (Billings and Cyberduck) that “This program was downloaded from the Internet… blah blah blah” This normally happens once for a program then goes away after you say “OK”, but this was happening everytime I opened those two programs.
