When you follow directions for use of AlgaeCal Plus and Strontium Boost - we guarantee you will see increased bone density in EVERY follow-up bone scan you have while using these 2 products - or we will refund every penny you paid for our products between your scans. This guarantee extends to every scan you have for the next 7 years! Also, if you are unsatisfied at any time you can return my product for all full refund, no questions asked! Click Here for Details
Is it plugged in? Is it turned on?
JMeter is a tool used to “load test applications and measure performance”. Its usage is traceable back to your computer and should only be used against sites that you are responsible for.
Set up the Environment
JMeter requires Java. At the command prompt, type: (Under Start menu > Run: cmd)
Currently Apache JMeter 5.0 Requires Java 8 or 9. If you get a message about java not being recognized as an internal or external command, etc. then it probably is not installed.
Get it here: https://www.java.com.
Click ‘Download for free’, listen to them complain about Chrome, then click ‘Agree and Start Free Download’. Links to system requirements, etc. are available on this page.
Run the Java installer that you downloaded, click ‘Install’, then click ‘Ok’. Let it do its thing, read about doing updates regularly, then click ‘Close’.
Close your command prompt if you did not already, and open a new one to check your java version again. It should show something like “java version 1.8.0_191”.
Download JMeter here: https://jmeter.apache.org/download_jmeter.cgi.
Under Binaries, click the ‘apache-jmeter-5.0.zip’ link. Download then extract the zip file.
In the extracted ‘apache-jmeter-5.0’ folder, browse to the bin directory and run jmeter.bat.
This loads the JMeter gui.
For step by step instructions on how to use JMeter, read this: https://jmeter.apache.org/usermanual/get-started.html
Ultimately, the process is:
- build a test plan
- run the test plan
- read and analyze the test plan results
Watch this space for future posts on performing each of these.
Don’t forget to post below with your questions and comments!
Instructions for dev environment setup and Drupal 7 install on Windows 10
Get and install EasyPHP DevServer
- EasyPHP download
- Click to download DevServer 17
- After a few seconds, the download will automatically begin
- Run the installer: select language, install directory (default is fine), create desktop icon
- Click Install
- Select to launch, click Finish
- An icon will appear in the notification tray, click on it, select ‘open dashboard’
- It should open a window to 127.0.0.1:1111 (localhost, port 1111).
- If you get an error: “This site can’t be reached”, then try to ‘start servers’ from the information tray menu. If the dashboard still won’t come up, then reboot your computer
- When your computer comes back up, double click on the DevServer 17 icon on your desktop
- An icon will appear in the notification tray, click on it, select ‘open dashboard’
- It should open a window to 127.0.0.1:1111 (localhost, port 1111).
- Click to start the HTTP server and the Database server
Install Additional Tools
Set Up Your Project
- If you don’t have one, create a GitHub repository at github.com. Click the checkbox to create a README file, so you can clone the repo right away.
- Click into the repository, click Clone or Download > Open in Desktop
- Copy the local path from the dialog and click Clone
- Go to the EasyPHP Devserver dashboard
- Click Add Directory
- Add a working directory name… it will be used as the pseudo document root for this project. It will be prefixed with “edsa-“, do not include spaces
- Under Path to the working directory, paste the path that the repository was cloned into, click ‘Save’
- In your IDE (Eclipse, Zend Studio, PHPStorm, etc.) add the project, sourced from the local GitHub repo location
Prepare Drupal 7 files
- Drupal 7 install guide (for reference if needed)
- Go to the Drupal Project Page
- Click on the Drupal core 7.x version button (7.59 at time of writing) to download Drupal 7
- On the project page that comes up, click ‘Download Zip’
- Unzip the downloaded file then move the contents of the “drupal-7.59” directory to the project’s GitHub repo directory
Create the Project Database
- Go to the EasyPHP DevServer dashboard
- Click “Open” next to the MySQL Administration header
- Click “User Accounts”
- Click “Add User Account”
- Enter a user name, select “Local” under Hostname, select “No Password” under Password
- Under “Database for user account”, check the box next to “Create database with same name and grant all privileges.” Click “Go” at the bottom of the page.
Install Drupal 7
- Go to the EasyPHP DevServer dashboard, and click to visit your project site in browser
- You should see “select an installation profile”. Select ‘standard’ and click “Save and Continue”
- Select your language and click “Save and continue”
- If you see the “Verify Requirements” page, use the install guide to resolve any problems.
- Make sure MySQL is selected, and enter the database credentials: enter your database name, the user name, leave password blank. Under ‘Advanced options’ make sure the host is localhost. Click “Save and continue”.
- It will run for a minute with a progress bar. When it is done, configure the application: Site name can be changed now or later (to something human readable), follow instructions to fill out the rest of the settings. Site Maintenance Username, etc. is the Username you will use to log in with. Click “Save and continue”.
- Click to view your site.
- In a production environment, you would need to secure your site: change permissions on the sites/default/settings.php file to make it essentially 644… readable by all, writable by the owner
It looks like the Drupal 7 User Guide is designed to be a walk-through. There is also this page that has lots and lots of good info about the different components of drupal and their relationships, in addition to links to lots of other informative articles.
Please comment below or contact me if you have questions, or if you find problems with these instructions!
Been meaning to move my dev environment onto my local machines instead of developing directly on the server. There are lots of benefits to this: it will save me from setting up dev hosts on the server, for one. And this will help keep commits in github from being so granular and cluttering up the place. Also, it should save a few seconds every time I want to test what I’ve done, which will save me at least a few minutes every day. Plus every single time I commit code to test, it is followed by one more commit usually with the comment ‘doh!’. Would be good for my ego to eliminate that as well.
To make a local environment for dev, in the olden days we would get each application (apache, mysql, php) and download or compile them locally, then install, etc. All updates were manual. In today’s world, we have quite a few options for install suites that provide a complete local environment.
I did some initial research, and installed a couple that didn’t work well, then finally did what I should have done in the first place and consulted phptherightway.com – my first and often final source for advice regarding current best practices. From php the right way’s home page, navigate under ‘Getting Started’ to ‘Window Setup’. There you will find a brief write-up, including a list of integrated development environment bundles.
After reviewing the offerings under each of the recommended sources, I installed EasyPHP – DevServer 17 (http://www.easyphp.org) on my Windows 7 desktop host, which takes most of the abuse in terms of installing unknown software, etc. these days. So far, the download page seemed a little sketch, but it doesn’t seem to have installed anything undesirable. I had problems with the menu in the notification area immediately after the install – it would not recognize any of the menu selections to start servers (or to exit the DevServer itself). The dashboard link, which goes to the localhost with a custom port, opened to an error in my browser. When I navigated to just localhost (port 80), there was a link to view php_info() output, but nothing else.
When it let me open a second instance, I knew it was having severe problems and shut everything down then rebooted. After my computer came up I was back on track with the Getting Started guide, here: http://www.easyphp.org/documentation/devserver/getting-started.php. I was able to start the servers and access the dashboard.
The dashboard has some good options – you can clearly see whether servers are running and their versions, configure directories to serve as the document root (although missing a Browse button) and access those sites. There is also a link to phpMyAdmin, which is a great tool to have available. And there is a novel php code tester interface, essentially a snippet tester.
Next move was to configure DevServer to work out of my existing GitHub repository directories. First I picked a project without a database for now, and was able to access a directory list in the dashboard interface and open the site in my browser, from an automatically created sub-directory under the localhost document root. Any links or images using an absolute path will obviously not function correctly. Otherwise, that worked easy enough.
The real test is to configure databases for my applications in the new test environment. The phpMyAdmin interface worked fine – I created a new user for my dev site, specific for this application, and opted to have it create a database. Then I exported the data structure and initializing data from my existing database and was able to load that no problem.
Next, I created a working directory in DevServer that pointed at my repo directory for this project, just like before. Finally, I updated my projects config files with the correct database credentials. I clicked on the “open in browser” link on the dashboard and… drumroll….. wah wah. It thinks my document root is: C:/Program Files (x86)/EasyPHP-Devserver-17/eds-www .
Luckily, my application is able to work in a subdirectory if it is configured, so presto-changeo, bummer: “Could not connect to database server.” Ok, so long story short, the database comes configured to allow anyone from localhost, and to otherwise require ssh, so I changed my new user to have no password, and to only be able to log in from localhost. That seems fine, but then I get “Unable to select database.” Ugh! So not sure how I fouled that up, but I created a new user then granted permissions for the application database and finally it connects!
Just in this short window I can already see how dev changes and testing can be much easier with a local environment. It realistically took me about 20 minutes to get up and running including troubleshooting. In all, definitely worth it!
The following is generated by a php script, to demonstrate WordPress integration. Some of the more fun moving parts: gulp file use for sass compiling, Wisteria video timer trigger, REST API integration for data retreival. Created from a Photoshop file.
4 Capsules Per Day
|Amount Per Serving %DV|
|Vitamin C 50mg
(as calcium ascorbate)
|Vitamin D3 1600 IU
|Vitamin K2 100 mcg
|Calcium 720 mg
(from algas calcareas)
|Magnesium 350 mg
(from algas calcareas and magnesium oxide)
|Boron 3.0 mg*
|*Daily Value (DV) not established|
2 Capsules Per Day
|Amount Per Serving|
(from Strontium Citrate)
|*Daily Value (DV) not established|
CEO and Co-Founder,
- Marques A, Ferreira RJ, Santos E, et al. The accuracy of osteoporotic fracture risk prediction tools: a systematic review and meta-analysis. Ann Rheum Dis. 2015 Nov;74(11):1958-67.doi: 10.1136/annrheumdis-2015-207907. Epub 2015 Aug 6. PMID: 26248637,
- Riggs BL, Melton LJ 3rd. The worldwide problem of osteoporosis: insights afforded by epidemiology. Bone. 1995 Nov;17(5 Suppl):505S-511S. PMID: 8573428
It’s been an amazing past few months with lots going on! Maybe I will catch you up on it someday, winky-face…
But picking up where we left off… Zendcon!
Had such a great time last year that I signed up blind early bird! My particular focus last year was on asynchronous APIs and composer. I also attended a fascinating talk on open source AI projects.
Honestly, I was somewhat disappointed with the async solutions. I realize that conferences are for showing off the latest and greatest, but unfortunately that meant the currently available option is out of my reach for now. Wound up sticking with the solution that I have in place – will post the code if I get a chance.
But, if you don’t work on a xenophobic legacy codebase and have the luxury, then honestly I would recommend Postman or some other subscription service for reporting and monitoring API requests and request handling.
The talks on Composer, on the other hand, were so incredibly useful. It is akin to the moment that I learned about version control early in my career. It is easy to install, easy to configure, and easy to use. The single greatest benefit to me has been the ability to create private packages in conjunction with private github repositories. Although, full disclaimer, I don’t have autoloader working. I haven’t done much to look into that mind you, but it is a minor inconvenience at worst.
The upside is incredibly accessible and maintainabe codebases. It’s a no-brainer for anyone with multiple projects that have any overlapping custom components. It has been much easier to start new projects without additional maintenance overhead. For a small shop like mine it makes things possible that we could never have managed before. Three thumbs up!
So needless to say I have high expectations for the conference this year and can’t wait for Vegas in October!
Every year my New Year’s resolution is to try a little harder – and I am pleased to announce that I am headed in the right direction! Here is my completely un-humble brag:
Last night I performed a weekly launch and COMPLETED IT! I didn’t wake up to a pile of documentation to do, or a bunch of orphaned branches that would hang around for a few weeks. I don’t have any admin or accounting to finish. Email notifications were all sent. No lingering related support items. No cards to archive or channels to close.
I did it. Completely. I was up until midnight, but I did it.
Way to go, me!
I often find life’s axioms can apply to coding. Today’s lesson: be your own best friend!
Not complaining, and definitely not bragging, but sometimes I experience “genius strokes” – typically while coding. Unlike a stroke of genius, they can last hours at a time and the results can be difficult to live with in the long run.
Did I just write an entire CMS framework in a couple of hours and less than 1000 lines of code? Yes! That’s great! Do I remember how it works the next day? Maybe. Will I be able to understand and modify it in a meaningful way a month from now, when I’m not stroking out? Good luck… The dev team members at infsoln always groan when I announce a project involving genius stroke code. They know it will be difficult to comprehend the logic and figure out the inevitable clever twist that makes the whole thing work. We all hate clever.
One of the things that makes this code so difficult to work with is that it isn’t documented. Whether it’s because it seemed obvious at the time or because the ideas were flowing rapidly or even if I simply didn’t want people in my code, the lack of description and explanation is a real bummer. Just a few words could save those who follow (including myself) a tremendous amount of time and headache. It may sound psychotic to wish I had left notes to myself, but I think this almost daily. This needs to be a natural part of code-writing, as automatic as semi-colons and curly brackets.
Another issue I find when coding rapidly is terrible variable names. $spa might have made perfect sense when I created it, but wtf is that, honestly. If it requires even an instant of interpretation then it isn’t a good variable name. Every distraction like this is yet another item to temporarily remember in order to hone in on whatever it was that I was in there looking for in the first place. Knowing that my virtual desktop could catch metaphorical fire at any given moment on any given day, the easier and more direct the route to a solution, the better.
And thirdly (I won’t say lastly as there are so very many more basic things I can do to set myself up for success), DON’T HACK SHIT IN. Hacked together code full of shortcuts and lazy coding is nothing more than prototype code. If it makes it to production I am guaranteed to have future headaches. I need to take a few minutes to go back and figure out the correct variable name, or put queries in a data access object, etc… my code quality will improve drastically!
The conclusion, after a long session of trying to interpret my own code-writing, is that while it is fun to run and frolic freely in the meadow of logic, if I leave myself a few signs pointing back to reality then I will enjoy visiting the place again in the future. And it is always more fun when I bring my best friend with me!
When my next door neighbor and generally awesome person Kelly said she wanted a blog site the possibilities seemed endless. My company has been doing a lot of websites this year and I had high hopes of integrating a third party blog script into our custom rapid development framework. Its been a couple of years since I installed a blog and so of course I went out and looked at reviews, hoping to find something new.
Looking at reviews and feature lists, my first choice was called NibbleBlog. I read reviews, I read their site, and even went to GitHub for a quick code review. Having been burned by deploying small open source software packages in the past, I headed over to look at their open issues list. The first request was from a couple of weeks ago but was unanswered, regarding a bug when uploading photos. The lack of reply seemed to hint at abandonment but I read on. The next issue request was from a user who enjoyed the software package, but wanted to see support for seo-friendly urls. Buried in the ‘me too’ responses to that issue request was a quiet note from the package author stating that the software was no longer supported. Had I not thoroughly reviewed the open issues then I never would have known. Obviously I’m not going to deploy deprecated software, so I moved on.
I returned to the lists of options and sadly dismissed each one, all no longer supported or missing critical functionality. Many that are listed as free are actually not, and I have several reservations about purchasing blog scripts. Few offer support, and many are hosted on scary looking websites. Everyone’s first web coding project is a blog, and there’s no such thing as a free preview when buying scripts. There truly is no telling what the author’s skill level was. So, running out of time, I gave up and deployed WordPress.
Don’t get me wrong, WordPress is fine, but it doesn’t advance my original goals of creating a custom blog module. And I’m still salty after Polish spammers took over my last WP install and were hocking kayaks on my home page (not kidding). I get a lot of work requests to make custom WP apps, but I really wanted to offer a simple alternative to my clients.
So I am sad to report that, like Wal-Mart, WordPress seems to have effectively eradicated the little guy in the CMS and blog world. If you know of a php blog package that can integrate into an existing website, be sure to leave a comment. In the meanwhile, welcome to my WP blog!