Blog posts by Geekyboy – Adam Culp

I needed to perform a demo of a tool where I would utilize my mobile device (phone) to perform an action, and it caused a reaction on my laptop.  However, part of the “WOW” factor is to mirror my mobile device screen onto my laptop so the viewer can see both the mobile device and the web browser.

Thanks to Apple’s AirPlay this is relatively easy for the iPhone with the purchase of 3rd part software like Air Squirrels Reflector, but I don’t have an iPhone. (I can never figure out how to switch between apps, or how to go back if the app developer didn’t include a back button in the app.  But I digress.)  Instead I have an Android device, which has a much larger user base, and I really didn’t want to switch.  Unfortunately nobody has created a 3rd party application that utilizes the Cast Screen functionality of Android in the same manner as the AirPlay.

In searching I found many solutions that required the user to “root” their mobile device.  This really wasn’t an option for me.  I have a Google Nexus device, so I’m not really held back by mobile vendor limitations, lock downs, or pre-installed software.  No need to “root” my device.  I’ve rooted/unlocked other mobile devices in the past, and since I’m not a mobile developer, I feel no need to tinker with what works for me.

I did manage to find a couple other solutions (one with the help of my co-workers) that did work without altering my device software, or installing applications on my laptop.  Well, that is not entirely true.  Both of the solutions I’m about to share did require the Java runtime environment to be installed, but I consider that a mute point since most computers these days already have it installed for one reason or another. (Most developer IDE’s already require it, so I already had it.)

Step 1 – Ensure you have JRE

As I said, for this to work you will need to have the Java Runtime Environment of some sort installed on your system.  If you don’t already have the JRE installed you can do it at http://java.com.

Step 2 – Connect with USB

You must connect your Android device to your PC via USB connection for this to work.  As of this writing I have not found a way to make this wireless.

Step 3 – Enable Developer Mode

By default Android devices do not come with Developer Mode enabled.  This mode is needed so we can take advantage of debugging via USB tether.

On Android devices prior to 4.2 you could set USB Debugging from the settings…easy-peasy.

To enable this on Android 4.2+ go into Settings->AboutPhone and tap the Build Number 7 times.  The device will inform you that Developer Mode is now enabled.  Click back to hit the previous screen and you will now see Developer Options available.  Check the box for USB Debugging and you’re done.

Step 4 – Download the Android developer tools

For simplicity sake I only downloaded the standalone Android SDK Tools Only. (I had no use for the Studio.) I did this at the URL http://developer.android.com/sdk/index.html#Other, then unzipped the file to a place of my liking.

After making the file ‘/tools/android’ executable I ran it on the system.  This opens the Android SDK Manager window.  The purpose for this is to download and install the needed packages to allow us to “develop” Android apps.  I didn’t change a thing and simply clicked the button that said “Install n packages”. (Note: n will be some sort of number.)

It took awhile for the manager to do the update/download, but after it was completed I simply closed it.  This would have downloaded a bunch of things, but the most important for us is ‘/platform-tools/adb’ which is required to mirror our device screen to the PC. (Make sure this file is executable as well.)

Step 5 – Add locations to the PATH

For this screen sharing to work you will need to add two folders of the Android SDK to your PATH: ‘/platform-tools’ and ‘/tools’.  I did this by editing my .bashrc file as follows:

export PATH=$PATH:/home/aculp/android-sdk-linux/platform-tools:/home/aculp/android-sdk-linux/tools

Step 6 – Download Apps

There are two possible apps to use to do this:

• Android-Screen-Monitor – https://code.google.com/p/android-screen-monitor/
• Droid @ Screen – http://droid-at-screen.ribomation.com/

Both carry the same sorts of functionality, however Droid @ Screen is a bit more mature and makes additional options a little easier.  One thing I didn’t like was the need to have an extra window open for the settings.  Due to my being a fan of simplicity I have been using Android-Screen-Monitor.

Both apps are a simple matter of executing the jar file using java and they just work.

Step 7 – Launch it!

Now it is simply a matter of launching either the Android-Screen-Monitor or Droid@Screen application. I did this via CLI like so:

$ java -jar asm.jar

NOTE: This command assumes we changed directory to where we downloaded the Android-Screen-Monitor jar file.

Conclusion

If you have questions or comments please post them.  I will return to this post and tweak it a bit more to become really easy to use, but for now this is mostly what I did.

No matter what OS you’re cloning, using “dd” via command line will still work.  I personally tested while cloning a 1TB Ubuntu hard drive to a fancy new 1TB SSD.

Backstory: I purchased a new Dell 7737 laptop with a 1TB hybrid drive, which turned out to be slower than watching paint dry compared to the old SSD I’d been using for a few years.  Otherwise it is a kickass laptop.  So I purchased a 1TB SSD after finding they are roughly 50 cents per GB these days…very affordable.

First I put the new SSD into USB caddy I had laying around for backup purposes.

Next I created a bootable USB stick with an Ubuntu ISO image following the instructions at:

Windows = http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-windows
Ubuntu = http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-ubuntu
MAC = http://www.ubuntu.com/download/desktop/create-a-usb-stick-on-mac-osx

With the USB stick created I booted the system to Ubuntu using the USB LiveCD disk image.  It may require a BIOS change to enable the PC/Laptop to boot from USB device.  Doing this will not make any changes to your current hard drive as long as “Install Ubuntu” is not chosen.

Once booted up I was able to use Gparted, which is a standard app on the LiveCD, to create a new partition table on the new drive in the external USB caddy.

I then used fdisk via command line to find all disks and gain their identifiers needed.

fdisk -l

With the new partition and the identifier of the USB drive I was now ready to initiate the copy.  I used the following command to do that:

dd if=/dev/sdc of=/dev/sdb mb=8M && sync

NOTE: ‘if’ = read from and ‘of’ = write to.

It takes a very long time for this to finish up, especially with larger drives, but the end result was a working drive with my data on it.

After completion I simply switched out the SSD from the caddy with the internal HD in the laptop and all worked well.

Good luck!

When it comes to ignoring files in a git repository I do something I think many others have done.  I’ve added user level settings files to my .gitignore because I don’t want them included in my git repository.  You know, the files created by an IDE, operating system, or other applications.  Such as ‘.project’ created by Zend Studio or ‘.idea’ created by PHPStorm, and there are many others.

While it may be acceptable to add them to the .gitignore file in a private repo, should they be ignored in a publicly shared repository?  To answer this let me explain that I believe in “freedom”, and think everyone is entitled to do what they want, as long as it doesn’t hinder someone else’s freedom.  This is important when it comes to code.  Therefore, these files should NOT be ignored in the .gitignore of a public repo because someone creating a clone of the repo may desire to do something different.  So marking these files to be ignored, or not, should totally be a personal decision made by the user.

However, there is a way to have our cake, and eat it too.  We can inform our local instance of git to have a system global .gitignore file.  Therefore while the individual repository has a clean .gitignore file, with only references specific to the project, we can still have our user level ignores in place.  Here is how to do it.

From command line issue the following command: (command is non-Windows because of the file location, I’m not sure what it would be on a Windows machine, so perhaps someone can comment with a Windows friendly command)

$ git config --global core.excludesfile ~/.gitignore_global

This command creates a global setting in our systems git configuration informing git of an excludes file containing additional files to ignore globally.  The file name will be called ‘.gitignore_global’ and will be located in the users home directory.

Adding this –global config setting to git does not create the file for us, so we will still need to create this file in the location we specified. (The home directory in this case.)  Here is what mine looks like:

.idea
.buildpath
.project
.settings
.vagrant
.DS_Store
nbproject
.thumbs

Meanwhile my project level .gitignore might look like:

/vendor
local.config.php

For more on this topic, and perhaps a better explanation, please see https://help.github.com/articles/ignoring-files.

Over the past couple years I’ve noticed a rise of good companies no longer outsource offshore to save money, instead they outsource because they can’t find developers here.  Notice, I said “good companies” because there are still poorly managed companies who believe the hype of offshore developers saving them money.  Since the poorly managed companies will eventually join the ranks of failures with their next social “thing”, we’ll stay focused on good companies here.

I’m sad to see the dwindling number of developers available to fill a growing number of jobs.  Local colleges and universities don’t seem to be helping, with outdated course material and terrible intern programs that aren’t helping prepare grads for “real” jobs after graduation.  Couple this with most companies and recruiters simply draining from the pool without giving back, and governments sinking more and more of our hard earned taxes into already flooded non-tech related fields.  The end result is higher unemployment, folks with a degree who can’t find work, and the vicious cycle continues on and on.

We have a pretty large tech hub here in South Florida, but we are losing developers without re-filling tomorrow’s developer pool.  Where are developers going?

• Good students are picked up from companies outside of the area.
• Other students tend to work in unrelated fields because local companies are unwilling to hire entry level and train. (myth of getting to market faster)
• Experienced developers move to other areas with better culture and/or higher salaries.
• Those developers who stick around often burn out after a few years because companies didn’t treat them well.

If we continually cut down trees in the forest we eventually find there are no more to cut down, leading to an environment where companies and recruiters head hunt among themselves to stay afloat.  Hint: This doesn’t help developers, it doesn’t help the community, and it doesn’t help companies (higher acquisition, training, and retention costs).

Companies removing developers from the market, but not contributing so other developers can be created is a fairly large problem.  It is not sustainable, and we need to make companies aware of this, to prevent a very dismal tomorrow.  The folks over at Tech.Nottingham wrote a great blog post about this, so go check it out for more details on how you and your company can start contributing for a better tomorrow. http://www.technottingham.com/news/2014/7/29/tech-companies-are-you-contributing-or-just-consuming

For companies or techs who doubt this, look no farther than the nearest event happening in your own back yard.  Look down…at the companies sponsoring these events.  Are they local companies?  Are they companies that are interested in growing the local community?  Is it your company?  I’ll close with that thought.

Thanks to a friends tweet I found a handy post on “The Week” which highlighted schedules of successful people and productivity tips around optimized daily appointments.  Much of it rang true with me, so to prevent me from losing sight of it I decided to reiterate it here.

• Early morning

  • Wake early, to get things going prior to insanity starting. Before goals have competition.
  • Many stick to a morning ritual.
  • Set concrete goals for the day.

• First things

  • Tackle important things early/first.  The first couple hours of the day are our most productive, don’t waste them on email and/or meetings.
  • Escape to a quiet place, distractions make us stupid.  Avoid “drive-by” meetings, they will leech your most productive time.
  • We’re more disciplined in the morning, so take advantage of it.
  • Energy is high – do creative and challenging work.
  • Having troubles working on what is needed?  Get in earlier.

• Slowdown blahs = regroup time

  • Take a break, get a snack, take a power nap.  Often a power nap is like a reset button.
  • Re-enact the morning ritual to get going again.
  • Review goals of the day.
  • Focus on successes from earlier in the day.

• Afternoon lull

  • Energy is low – do busy work.
  • Best time for meetings.
  • Good time for a run. (personal note about me)
  • Distractions can be a benefit when we can’t focus.

• Evening

  • Before dinner write down goals for following day.
  • Do some relaxing activities.
    • TV, video games, eating are not relaxing. #mindtricks
    • Instead meet with friends, talk, play with hobbies. #truth
  • Get to bed at a good time, lack of sleep makes us stupid.

While at OSCON 2014 speaking about refactoring I gave an interview.  Here it is:

I know I should have done this a long time ago, but I finally got my hands dirty with Travis CI.  I wanted to set up a php project on github to use Travis CI to monitor the status, in case I forgot to run the tests prior to pushing.  Unfortunately it was not as easy as it’s made out to be.  But now that I’ve done it once, it’ll be easier next time.  So, here is how I tackled it.

First, creating an account and getting started was easy.  I simply clicked the “sign in” link on the Travis CI site and entered my github credentials which authorized Travis CI to connect to my account. (the site informs you exactly what Travis CI will have access to)  Once that’s done Travis gets all my repos, so I can then activate them for Travis CI.  If that doesn’t happen automatically there is a handy “sync now” button to coax Travis CI.

NOTE: To connect public repos you would use https://travis-ci.org, while for private repos you would use https://travis-ci.com.  While pubic repos are free private ones cost money, though you do get 100 pushes free to get you started.

Second, it’s now time to click the + and add a new repo to be tracked by Travis CI.  After clicking you will be presented with a list of your repos to choose from.  It is simply a matter of turning the repo ON by clicking the switch.  I also clicked the wrench to select the option to “Built only if .travis.yml is present”.

The structure of the app I added looks like this: (including all files needed for travis and unit testing) https://github.com/adamculp/api-consumer

Third, I needed to create the .travis.yml file with the directives needed to make it all work.  Here is what my file looked like.

Pretty simple.  Here is what it all means: I specified what language to use (php), and what versions of the language to test with (5.3, 5.4, and 5.5), I also instructed to have Composer install prior to any other scripts run (needed to ensure there was an autoloader, created by Composer), and finally I add the phpunit command and tell it where to find the phpunit.xml file (in this case it was in the tests directory).

Fourth, ensure that PHPUnit runs as expected locally.  Yes, you will need unit tests on your code.  That’s like one of the main reasons to do this in the first place.  Here is what my phpunit.xml and bootstrap.php look like:

The phpunit.xml file is fairly simple.  It informs where PHPUnit can find the bootstrap.php file (same directory as a the phpunit.xml), and sets a whitelist of directory where code can be found (some use a blacklist and specify not to use the /vendor directory), and what directory to find tests in (the current directory).

The bootstrap.php file specified by the phpunit.xml file is even simpler, as it only specifies where to find the autoload.php file created by the Composer install.

Fifth, take a quick peek at the settings for the repo on github and you will notice that Travis CI should be already set up and ready for something to be pushed.

Final, that’s it!  That is everything needed for Travis CI.  Of course this example is very simplistic, since the repo and tests are only on a single wrapper class I created.  But it’s good enough for a start, and if you need more the documentation is pretty good.  With these files created, all that remains is for me to commit changes to git, then do a push to origin at github.  Once the push to origin happens a Travis CI trigger at github fires and informs Travis CI to create a new build on a VM (virtual machine) then run the tests on the newest code.  After Travis CI finishes it lets you know with an email, and through the site. (green = good)

One last thing you may want to do is add the Travis CI image to your README.md at github.  This will allow you and others to see whether the current master branch had a successful build, or if it failed.

[![Build Status](https://travis-ci.org/adamculp/api-consumer.svg?branch=master)](https://travis-ci.org/adamculp/api-consumer)

Enjoy!

Yesterday I was approached by a developer, apprentice, friend, and sometimes mentor, who was having some personal issues.  I consider this person to be very strong, and capable of great things.  I’ve watched over some years, and I’m really impressed with their progress personally as well as professionally.  However, these facts only increased the shock of what they revealed to me, and must have been very difficult for them to share.

During the conversation it was revealed how they’re experiencing HUGE anxiety, complete with panic attacks, and are even consulting a physician who prescribed medication for it.  As this person spoke I could see the anxiety levels grow within through their body language , and witnessed the “deer caught in headlights” look as they wrestled on the precipice of going into another panic attack.  Though I had someplace I needed to be, I knew I couldn’t leave this person alone to struggle as I had so often in the past.  So I lingered, and we talked until the ebb had calmed.

My heart went out to my friend because I’ve dealt with the same feelings and problems, and had always done it alone. (Except for a few trips to the ER in past years to ensure it wasn’t really a heart attack.)  Oh, how well I can recall the feelings of fear and doubt.  Not knowing when my body will randomly boost my adrenalin to extreme levels that push me over the edge, fighting for my next breath until my chest loosens again.

Yes, I know I “seem” different in person as I talk loudly and laugh at conferences speaking to large groups of people.  It has taken me many years to get to that point.  And yes, inside I’m constantly forcing down the roiling anxiety that never truly subsides.  So don’t get caught up in the stereotypical idea that someone with anxiety is this lonely person crying while huddled in a ball in the corner.  That is not me.  My stress and anxiety doesn’t come from being around people, or from public speaking and such things.  I’m fairly social, but stress by other things such as deadlines, lack of requirements, distractions, fear of failure, and bad code, can be just as damaging.

Another common misconception is that anxiety is caused by the stress of the moment, which is simply not true.  A doctor I consulted with in the past informed me that anxiety can be caused by stresses from as long as six month ago.  So moving to a new home may seem OK at the time, but up to 6 months from now we suffer from the effects of the stress.  So, by the time we have an anxiety attack it’s too late to fix it.  All we can do is deal with the anxiety and push through it somehow.

For each of us the cause is slightly different, because we each struggle with our own problems and/or OCDs.  For my friend it was developer related stresses that many of us deal with:

• Working on a development team and not kept busy enough, so we internalizing the many things that weigh on our shoulders in such situations.  Will we be downsized because someone realizes we’re not busy?  What should we do with our time?  Is the company failing due to lack of feature requests?  Is it fair to collect a paycheck for filling time?  Am I not good enough?  And the list goes on.
• Working on a codebase that really needs a major refactor, but nobody will give the OK to do it.
• Witnessing a company rewriting an application, and realizing it’s as bad as the original.
• Wanting to contribute, but not knowing how to start.  Sure, it’s easy to say, “Just pick a project and start.”  But in reality it’s not that easy internally.
• Impossibly tight deadlines.
• Lack of requirements for a project.
• Relocating.
• Can’t seem to keep pace with new technologies.
• Open work spaces.
• Noises, motion, or cube drive-by ending in a meeting.
• Having questions, but not wanting to bother others by asking.
• Feel like an imposter. (see imposter syndrome)
• Feeling you’re alone, or perhaps you’re some “weirdo” because nobody else speaks about these things.

Some advice I gave, based on how I handle things:

• Tension Tamer tea by Celestial Seasons.
• Licorice root capsules twice a day when stress is high. (but as one commenter added, can cause side-effects)
• Learning how to say “no” to tight deadlines.
• Take a walk during lunch time.
• Read a book.  Not a technical one.  Something not related to work. Maybe something inspirational, or a fiction.
• Learned how to gather requirements for projects, and do proper time estimates.
• Running, or some other physical activity to get the heart rate up 20 minutes or more a day.
• Talk with others, even though we would rather be alone. (maybe even professional listeners)
• Join, or create, a user group to pull others like me together.
• Teach others how to create better code, so I don’t need to see bad code as often. (never ending)
• Work from home.
• Get a new job. Not a new profession. (extreme, but sometimes it’s the only way)
• Get an annual checkup, so I know I’m healthy and not having a heart attack when anxiety kicks in.

I don’t really have the answers, nobody does.  But felt I should create this post and put it out there.  Perhaps others will read it and realize they’re not alone.  And sometimes just knowing that can help lessen the stress levels.

How do you handle the stress?

NOTE: I received permission from my friend to share this story, so it wouldn’t cause any more stress and anxiety by sharing it without their knowing.

While trying to test the sendmail feature of Zend Server 6.3, on Ubuntu and CentOS, there was a bug.  I discovered that utilizing the Mail Preferences area of the Adminitration->Settings page and sending a test email to myself with the Sendmail option ended in an “Unknown error”.

The error returned by Zend Framework 2, which is used by Zend Server 6 was a generic error (Unknown error) if Sendmail returned an error status, but an empty error message.  Not much help, or was it?

Since the error appeared to be caused by Sendmail not returning a proper error the search for the issue led there.  See where my logic was going? My next step was to test sending an email with the PHP mail() function, and see if that shed any light on the issue.  Unfortunately it worked, which meant the issue was elsewhere.  But if the error wasn’t with PHP, Apache, Sendmail, Zend Server, or Zend Framework, where could it be?

At this point I enlisted one of my coworkers, Roman Basayev, who nailed it down.

Of course!  Zend Server on Linux installs Lighttpd for the Zend Server gui, and there must be a setting there for using Sendmail.  Sure enough in the file ‘/usr/local/zend/gui/lighttpd/etc/php-fcgi.ini’ there is a setting for ‘sendmail_path’ and it was empty.  So PHP running on Lighttpd was not able to find Sendmail, and therefore was not getting a decent error message.

The fix:

In the file ‘/usr/local/zend/gui/lighttpd/etc/php-fcgi.ini’ update the ‘sendmail_path’ to be ‘/usr/sbin/sendmail -ti’.  These are the paths on Ubuntu and CentOS, others may vary.

sendmail_path = "/usr/sbin/sendmail -ti"

After restarting Zend Server, all should be good  to go now.

This morning a tweet caught my attention prompting me to read this post by Gary Hockin also known as @GeeH. (There’s just something about that voice.[inside joke])  In the post he talks of his experiences while attempting to simplify code in a project, and in the process uncovers hidden dependencies that increased the codebase significantly in order to gain the benefit of a mere 100 lines of code.  He also highlights that in today’s mainstream PHP development, where many are using Composer to blindly include packages into applications, we may not fully understand code being pulled in with the consequence of accepting responsibility to maintain those additional packages as well.

I’ll wait a second while that sinks in…

Yes, that’s right.  If you include additional packages and libraries into your application you’re accepting the responsibility to maintain them.  No, I’m not saying you are responsible for contributing to the software package…unless you care to.  What I’m saying is you are now in charge of updating the software within your application, which now includes additional packages created by others.  As security holes get fixed, or new versions come out fixing bugs, it is up to you to ensure you update these packages in your applications which include them.

You’ve been living in a dream world Neo

Ha, didn’t think about that, did you?  If you did, Bravo, you’re behaving like a professional.  For the rest, welcome to reality.  Now go update the applications you’ve neglected.  But first a side note.

I’m not saying Composer is bad.  Actually I think the opposite.  Composer is awesome, and you should be using it if you’re not already.  As in the post by Gary above I’m simply saying it’s our professional duty to know what we’re asking Composer to do on our behalf.  Use it responsibly and do a bit of research so you’re not blindly including potential issues, bugs, security holes, and nightmares to maintain in the future.  Then if you’re satisfied with what you see, go ahead and “require” away.

But wait!  Don’t just look at the packages you’re including into your codebase.  Also take a look at their dependencies as well, because you are also accepting them in the process.  Know what you’re saying “yes” to.

Past knowledge

None of what I’m saying is new stuff.  A while back, in the beginning of 2012 (I thought it was earlier for some reason), Ed Finkler @funkatron wrote the original MicroPHP Manifesto to voice his concern over many frameworks starting to grow in size. (NOTE: Later there was a separate domain dedicated to housing the MicroPHP Manifesto, but I like the original better because the blog post associated with it helps highlight why it’s a concern.)  I encourage you to check it out and consider the meaning, and how it relates to your projects.

Again, nobody is saying large full frameworks are evil or other libraries should not be used.  The idea behind all of this is to caution, so you go in with your eyes open and “know” what you’re including in the codebase.  Know the responsibilities accepted by including other libraries.

Happy coding!