Tuesday, February 18, 2014

iOS7 TDD w/ OCMock and Xcode5 Linker problem: -ObjC

I'm setting up a new project, using CocoaPods and a couple of libraries (TestFlight, OCMock, AFNetworking, et al). While CocoaPods may not work well with private repos among public repos, I find it quite useful, especially if someone else wants to join my project quickly.

The biggest pain points I had were linking, which means unless I know in advance that linkers need to be forced for each individual library, I'll get some obtuse error, like:

ld: file not found: -ObjC
clang: error: linker command failed with exit code 1 (use -v to see invocation)

What that really means is I needed to update the flag in my specific project to  -all_load.

Know how to do that? I didn't originally, but finally figured it out. Under the specific project I'm targeting (my tests in this case), in Build Settings -> Linking, I look for the "Other Linker Flags" and make 1 teensy change:

remove '-force_load'
add '-all_load'

That's it!

Oh, and if you're referencing any old OCMock tutorials, please don't use SenTestingKit.framework. You don't even need a header file for test. Just use the following inside your main class:

Now OCMock works great and my code works. Now to write some tests!

Thanks to this blog's comment for helping: Nick Hart

Tuesday, January 7, 2014

Google Glass - getting started

I'm a developer, and sometimes I get to explore new technologies. In 2014, I get to be a Google Glass Explorer. No, I'm not the first to this game, and there are several others out there, and heck, Google might release a newer product in the next week that would make what I just got obsolete, but right now I'm learning the ropes on my device. I've only been allotted a little bit of time, but in that time, I've learned a few things that I'm sharing for my own edification (and feel should've been included in a setup guide, or something, but was just left to explore/discover on my own).

Simply going to http://glass.google.com doesn't yield anything useful because you don't even have a login there. Oh, and it redirects you to http://www.google.com/glass/start/. That's not intuitive nor helpful, not to mention there is no login...Ok??

Simple stuff:

  1. Get the app
  2. Pairing with a device
  3. Connecting to a WiFi Network
    • https://glass.google.com/u/0/myglass
    • Getting to this site wasn't intuitive either. Just going to glass.google.com was to see a large advertisement, but nothing about logging in and viewing my app. 
  4. There's a community 
  5. Search for posts
    1. inside the community, it'd be helpful if there was a stack-overflow style search, question and answer view.

Google, next time please at least give me some directions to get the basics down. Even my iPad had these initial things available. Better to over-communicate than assume your audience knows what to expect. If you want common users to understand and learn how to use your device, you need to make it as intuitive as possible. Nothing of my experience has yet to be intuitive.

Even a simple directive to point me here https://support.google.com/glass/?hl=en#topic=4363345
would have made a world of difference. Honestly, there has to be a better way to launch this product so that dorks like me don't have to hunt. If I wanted that, I'd go learn Unix. I want to use Glass to be more productive, and so far it's been a PITA. Let's work together to make this better. Deal?

Friday, October 25, 2013

Shell script to download files from anywhere

As the title suggests, this is just a simple script I figured out for downloading files. The list of urls for downloading are located in an xml document that I'm parsing, storing briefly, looping through and downloading what I wanted to a predetermined location (though that could be modified for user input).


read_dom () {
    local IFS=\>
    read -d \< ENTITY CONTENT

while read_dom; do
    if [[ $ENTITY = "xmlTag" ]]; then
if [[ $CONTENT != "null" ]]; then
wget -Nrkpl 0 $CONTENT -nd -Pdownloads
done < listOfXML.xml > temporaryXMLPage.txt

echo "File cleanup"
rm temporaryXMLPage.txt


Tuesday, October 1, 2013

Using Drush to deploy themes and modules to multi-sites on CentOS

Previously I discussed setting up multi-site on CentOS, now, using Drush, we can also download, enable, and set themes and modules for individual sites.  The default Drupal7 site gets all the glory of files downloaded to it, but the individual sites should be the ones showing the updates.

Steps to use Drush:

1) cd /var/www/vhosts/drupal7/sites/your.alternative.site
get into the correct folder that you want to have the theme enabled
2) drush dl theme
This is the last part of a url available from drupal, i.e. drupal.org/project/omega would use omega

3) drush en theme
This enables the them for all sites. From what I understand, the files themselves get downloaded to the main drupal7/sites/all/themes/ directory. Somehow Drupal knows to find the themes for each individual site, which in the next step we set as the default. Setting it this way makes it available to all sites to enable themselves, but not as a default for all sites. If you'd like it to be exclusive just for your one site, and not maintained for the rest of them, you might have to just move it around or not use drush for that...not sure? ask on the forums.

4) drush vset theme_default theme
This sets the default theme for the site that you're in. This is awesome because it does it only for the specified site. Even if I set the Drupal7 default site default theme, it would have no impact on the other sites because they all get their own choices.

5) drush pm-list --type=theme
this last one is pretty neat because drush has some pretty cool project management tools. this one just lists out all of the themes available for your main installation, including the package it comes with, the name, status, and version.


Monday, September 30, 2013

Drupal 7 multi-site install on CentOS6

Tricks to getting a multi-site Drupal7 installed on CentOS w/ Apache2, mySQL.

Follow these two posts, more or less. The biggest point of advice is that for each url that isn't a subdomain should point to the same url (i.e. your.alternative.site [] v. original.alternative.site [] v. original.alternative.site/different [])

These are suggested reading sites, but none of them are exact, always referencing ubuntu or other linux distros...mine was a little different.





The most important thing is to have drush installed (mentioned in my other post). That makes installing everything else move quite quickly.

This doesn't have to be the same for everyone, but here are my steps:
1) cd /var/www/vhosts/drupal7 (if vhosts or drupal7 doesn't exist, create them)
2) drush dl drupal
before step 3, make sure to create the databases you need
pre-3a) mysql -u userName -p (this user is your sql admin user name, same or different from drupal db's)
pre-3b) create database YourMySQLDbName;
pre-3c) grant all on YourMySQLDbName.* to YourMySQLUserName@localhost identified by 'PasswordYouSet';
3) drush site-install standard --account-name=admin --account-pass=admin --db-url=mysql://YourMySQLUserName:PasswordYouSet@localhost/YourMySQLDbName
4) vi /etc/http/conf.d/drupal7.conf (make this if it doesn't exist yet)
5) paste the following in, save, then quit:

Alias drupal7

<Directory /var/www/vhosts/drupal7>
Options +FollowSymLinks
AllowOverride All
order allow,deny
allow from all

6) vi /etc/http/conf.d/00_drupal.conf (make this if it doesn't exist yet)
one thing I've learned about apache is that the apache configuration file works alphabetically, and this file is the configuration for all virtualhosts (which allows us to have the multi-sites installed correctly)
7) paste the following in, save, then quit:
NameVirtualHost *:80

<Directory /var/www/vhosts>
  AllowOverride All

<VirtualHost *:80>
   ServerPath /drupal7
   DocumentRoot /var/www/vhosts/drupal7
   ServerName drupal7

8) apachectl restart

you should still be in the /var/www/vhosts/drupal7 directory
9) cp -a default/ sites/your.alternative.site/ (create it if it doesn't exist)
this should move over the files/ folder, settings.php and default.settings.php

10) chmod a+w sites/your.alternative.site/settings.php
chmod a+w sites/your.alternative.site/files

11) vi sites/sites.php
at the bottom of the file, you should add a line for each site you're installing. This hash is useful for finding the website and folders based on the apache setup (we'll get to that shortly).  Add the following:

$sites['nickname'] = 'your.alternative.site' (this is the folder path in drupal7/sites/your.alternative.site)

save and exit

12) now for your newly added site, we need to append info to the conf file so apache knows to redirect correctly to the sites.php file which will redirect to the correct folder which will show the correct site
vi /etc/http/conf.d/00_drupal.conf

at the bottom, add:

<VirtualHost *:80>
   DocumentRoot /var/www/vhosts/drupal7/sites/your.alternative.site
   ServerName nickname

repeat for each new site

13) Finally change the settings for the newest site added:
vi sites/your.alternative.site/settings.php

change the database information for your new site

14) now setup your site: your.alternative.site/install.php?

15) after setup, change the folder and file permissions back

16) pat yourself on the back, it's all done :) - maybe a drush script for multi-site would be useful?

Wednesday, September 11, 2013

Drupal 7 on OSX 10.8, with Apache 2.2, MySQL, and PHP 5

This post is more about my experience of using a local instance of Drupal on my OSX box. The following are links about resources I found extremely helpful. Basically, I installed 2 versions (Drupal 7.2 and , and you have to jump through some hoops because although OSX ships with Apache and PHP, you need to now enable some settings (via cmd line or other tools) in order to have web sharing activated again (the silly prompt from the Preferences Pane is now gone *insert_sad_face*)


1) This one helped me get the AMP stack going on my box (it also had some good step by step instructions about using phpMyAdmin)

2) Getting a few steps closer, this site gave me some more info about getting the info setup correctly for Drupal as well as AMP stack

3) A few stack overflow links

4) And I cannot forget the infallible directions from Drupal.org

5) and for good measure, once I installed phpMyAdmin, the help docs helped :)

So almost all of this got me to the right place, though it took a few hours to get screens working, and the DB didn't want to initially work. Why? Well, because the pdo_mysql.default_socket was not commented out...huh? Yeah, it didn't make sense to me for a bit. I searched lord google for things about the following error messages:

Warning: PDO::__construct(): [2002] No such file or directory (trying to connect via unix:///tmp/mysqld.sock)

Yeah, that kind of message didn't help at all, until I started changing my php.ini file around, and realized that that specific line, though correct (in a couple different ways, might I add), was wrong. My uneducated guess is that pdo_mysql is for Unix only, and as I am on OSX, it was wrong. Just commenting it out made it all better, install scripts started running on both installs, cats and dogs started sleeping together, and donuts began raining from the heavens...Ok, the last two didn't happen, but still, I hope this helps someone else besides me.

Tuesday, September 3, 2013

Setting up Jenkins on CentOS

It's been a while since I needed to install Jenkins, but I'm getting to the point where I'd like my code in GitHub (eventually pushed down to my own Git server on my CentOS box, once I figure out SSH), to be checked against tests whenever commits are made. Jenkins is the most kick-ass CI tool I know about. Setting it up is relatively easy, and getting it to play with Github is a cinch.

I followed the following steps to get it mostly up and running:

The only thing I'm not completely sure about is AJP. This is something outside the realm of my experience, and if it breaks, or if I have to learn more, I will, but for now, I want my box to pull against my repo, and if there's a change, pull, run tests, notify developers (rinse, repeat).

The only issue I really ran into was that Jenkins didn't run on the default java I had installed, so a quick update to my CentOS java via:

yum install java-1.7.0-openjdk

And now I have Jenkins up and running on CentOS!

Next is to figure out some good ole VPN fun, and then SSH (or the other way around).