Chicken Tender Wrap

Chicken Tender Wrap

  • Servings: 1
  • Time: 5-10 minutes
  • Difficulty: Easy
  • Print

Food of the Gods

One of the best things about my college experience at Grove City was the one unique, delectable item on the menu that — to date — I’ve never seen quite duplicated elsewhere.  So for any other Grovers out there that miss the taste of the Chicken Tender Wrap, here’s what I’ve come up with as a pretty darn close approximation.

Credit: Angela Starosta and Matt Schiavone for help piecing back together the recipe.

Ingredients

  • 1 large burrito-size tortilla
  • Diced plum tomatoes
  • Chopped iceberg lettuce
  • 2 Chicken Tenders
  • Ranch dressing
  • Hot sauce (optional)
  • White rice
  • Shredded mild cheddar cheese

Directions

  1. Put two frozen chicken tenders in a microwave safe bowl, and microwave for 1m30.
  2. Put the tortilla wrap you’re using on a plate.  Spread some diced tomatoes and chopped lettuce as a base.
  3. Take the (now hot) chicken out of the microwave, and put it in some hot oil in a skillet over medium heat for about 30-45 seconds per side.
  4. Take the chicken tenders out of the oil, put them on a cutting board, and chop them into maybe ½” chunks.
  5. In the same microwave safe bowl, put approximately equal quantities of white rice, and then shredded cheddar cheese in, and microwave for 1m30.
  6. Spread the chicken on top of the lettuce on the wrap.  Add your desired quantities of ranch dressing and hot sauce.
  7. Take the melted cheese and rice out of the microwave and combine it with a spoon until it’s mixed.  Add this on top of the chicken.
  8. Wrap, folding the edges, and slice it on a bias.  Enjoy!

Disclaimer: You’ll want a bigger tortilla than I’m using in the pictures.  I wound up having way too much stuff in it, and had to split it into two wraps after trying to wrap it.

Kiri Kiri Basara, a lesson in domains

Howdy!  If you’re here, one of two things happened.

Either you follow me on social media or my blog and found this new post, or you’re an anime fan watching Occultic;Nine, and saw the domain kirikiribasara.com in episode one and tried typing it into a web browser.  That domain — for now — redirects to here.

Here begins the lesson:

If you’re ever using a domain name in a movie, or a tv show, or in a presentation — any form, really — do yourself a favor and make sure you buy the domain before you go live.

It’ll cost you like $12, tops.  If your show flops, no big deal.  You don’t need to renew it for a subsequent year.  But if it takes off — or even if someone pulls up the domain just right after airtime, it’s a great tool to engage your users.

Or, you could not buy it, and some rando on the internet (hi there) can scoop the domain up for $12 on Google Domains.  Or cheaper if I wanted to go elsewhere.

Also, if you would like to start your own affiliate blog (like the domain was used for in the anime), I’d suggest building at WordPress.com!

As an aside, I’m not really looking to sell the domain, I just think it’s funny, but if anyone does desperately want the domain to run some sort of fan-forum or if the show’s producers are interested, feel free to drop me a line — the contact form on this site should work, and I’m fairly easy to reach on social media. 🙂

On the FDA and E Cigarettes

DISCLAIMER: While I may enjoy a rare cigar or pipe of tobacco perhaps once or twice per year, I don’t regularly consume tobacco products or nicotine. This post is more my musings on the bureaucracy and workings of the federal government.

Yesterday, the Food and Drug Administration (FDA) expanded its regulation authority to include “Vaporizers, vape pens, hookah pens, electronic cigarettes (e-cigs), and e-pipes are some of the many types of Electronic Nicotine Delivery Systems (ENDS)”.

I have concerns.

According to their press release,

Examples of components and parts of ENDS include, but are not limited to:

  • E-liquids
  • A glass or plastic vial container of e-liquid
  • Cartridges
  • Atomizers
  • Certain batteries
  • Cartomizers and clearomizers
  • Digital display or lights to adjust settings
  • Tank systems
  • Drip tips
  • Flavorings for ENDS
  • Programmable software

So, in short, it’s regulating all of the paraphernalia associated with vaping, and not merely the nicotine itself.

This is concerning to me.

Back in my college days, I used to smoke a (tobacco) pipe and cigars on a weekly basis with other students.  It was a communal event, and I learned to blow smoke rings.  As I’ve grown in the decade since then, I’ve lost the inclination to smoke, and really have no desire for nicotine.  I’ll occasionally smoke a pipe socially with friends once or twice a year, but I do enjoy blowing smoke rings.

As such, I own an electronic cigarette, and I purchased a quart of food-grade USP Propylene Glycol — the base liquid that most suppliers use when making liquid for vaping — and I’ll occasionally use it to blow smoke rings in my office.  No nicotine, no flavorings.

By my understanding, the FDA’s regulation of E-liquids has no limitation to “We only regulate E-liquids that contain nicotine” — in fact, they even state explicitly that:

If the tobacco product manufacturer submits a self-certification statement to FDA that the newly-regulated tobacco product does not contain nicotine (and that the manufacturer has data to support this assertion), then an alternate statement must be used on product packages and advertisements:

“This product is made from tobacco.”

Keep in mind that they are also broadly defining “Tobacco Product” to include all ENDS including all E-liquids and cartridges, atomizers, and even certain batteries. They must be labeled (falsely) that it is made from tobacco?

This feels like a significant overreach.

It strikes me that a similar regulatory effect could be accomplished, simply by exclusively regulating exclusively substances that contain nicotine. What is gained by having the Food and Drug Administration regulating the batteries that power vaporizers? Regulate the nicotine. If someone’s selling electronic cigarettes that come preloaded with nicotine? Sure, regulate that.  But leave the rest alone.

Two Weddings, One Family

I attended two weddings in the family this past weekend.  Two cousins, both on my mom’s side, tied the knot.

Saturday was a beautiful outdoor wedding at a farm in the countryside.  It was about a four hour drive away, which made it into a bit of an interesting day trip, but mostly uneventful.

Road trip time! 4 hours (each way) with two wee ones…no problem, right? 😳 #roadtrip #wedding #kids #halp

A post shared by Katherine Stephanis (@katherinestephanis) on

Sunday was a much easier affair to make it to.  A scant fourteen minute drive from our house, a “come as you are” ceremony.  Much easier to pull off with a seven month and three year old in tow.

And yet some members of the family chose not to attend.

Some members of the family who just drove eight hours round trip to attend another cousin’s wedding didn’t attend.

Why?

It was a gay (or, more specifically, lesbian) wedding.

❤️❤️❤️ #emandaud

A post shared by »«erin»« (@xtristatex) on

And it ranks up there in one of the most charming weddings I’ve ever attended.  The schedule on the program was titled “The Gay Agenda,” and they made jokes about “If this isn’t your first gay wedding, please keep the Bernie chatter to a minimum,” “Now that you’re all attending a gay wedding, congratulations, you’re all gay too,” and even “By the authority vested in me by Obergefell v. Hodges

My mind is just utterly blown at trying to comprehend the mindset that feels it’s more important to not attend a non-religious marriage ceremony.  If you’re Catholic, would you also refuse to attend the wedding of a cousin who was previously divorced and is now getting remarried?  Or do you only attend religious wedding ceremonies presided over by your own church?

I mean — what’s the thinking behind this? “If only I don’t attend their wedding, they’ll recognize the error of their ways, and abandon their sinful plan to marry the person that they want to spend the rest of their lives with?”

(btw, I’m pretty sure the bible doesn’t say anything about gay marriage, all the verses deal with the consummation, and I’m pretty dang sure you’re not invited to that part)

In the end, if I’m going to screw up in this life, I want it to be for loving and accepting people, not making them feel unwelcome or judged.  That’s my Pascal’s Wager. And that’s what I believe the message of the gospel is. The message of the Christ who dined with prostitutes.

Don’t approve of gay marriage?  That’s cool, don’t get gay married. 👍

But to not attend feels spiteful and unkind and wrong.

And I’m left feeling disappointed.

DIY Halloween Costume Smoke

I’m currently experimenting with possibilities for making a combo halloween costume that I could wear with my daughter this year, and I’d always wanted to be able to add a flair of the dramatic to costumes, and smoke is one of the best ways to do it.  Especially when it’s just a touch here or there.

I want it to be portable, and affordable.  Both of these are kinda requirements, honestly, for a once-per-year halloween costume.

In doing some research online, I saw an offhand remark from someone about e-cigarettes, vaporizers, whatever you like to call them, and the more I thought about it, the cleverer it seemed.  The recent pivot in the nicotine industry had driven down the cost of e cigarettes to the point where I could buy a “V2EX Automatic EX Starter Kit for E-Liquid” for about $12 at my local gas station.

Keep in mind, that this is just the e cigarette, not the ‘e liquid’ or the nicotine-laden stuff that makes it go.  By my understanding, that’s the far pricier bit.

So, e cigarette (rechargeable miniature smoke machine) in hand, I’d need at several more things: the fuel that makes it go (as I have no desire for nicotine or flavoring, I decided to forego the ‘e-liquid’), some sort of pump to operate the ‘draw’ that activates the e cigarette, and some way of getting the smoke from the e cigarette to where I want it.

The primary ingredient in ‘e liquid’ is a fun little compound called Propylene Glycol, and indeed you can buy it without the nicotine or flavorings much cheaper — if you have a Compounding Pharmacy anywhere near you, they normally sell it for probably about $10/pint — far more than you would conceivably need for a little smoke machine, but the point is that it’s cheap.  It’s also available on Amazon Prime.  You don’t need to mix it with anything, you can just pour it directly into the refill area of the e cigarette.  Granted, you may want to get an eyedropper or syringe with a blunt needle to do it with, so you don’t make a mess.

Now, we need a delivery method.

I had initially been envisioning some sort of one way dinky little plastic air pump with some hose on it that I could hide either under an armpit or behind a pushable button somewhere on the costume, but while trawling Amazon, found a great option — a 6′ tube with a siphon pump.  Going by its reviews, it’s made just as cheaply as the price indicates, but for our purposes — a one night costume — the price ($7) is right, and free shipping on Prime.

It is missing one-way valves, and I’ve got a set of those coming — again, Amazon Prime — but I don’t have them in hand quite yet.

In all, it’s come out to just about $30, $35 with the one way valves, and it feels totally worth it to add an incredible effect to a costume.

So, all things considered, I’m expecting to have a pretty fun instant smoke addition to a halloween costume this year.  And with the leftover propylene glycol?  Maybe I’ll just practice making smoke rings.  🙂

One friendly warning, though — you do not want polyethylene glycol.  That’s a laxative.  💩

Suffragette Landslide

A friend shared a trailer of the upcoming movie Suffragette on Facebook yesterday.  Apart from the fact that the movie itself looks amazing, I was struck by the stunningly beautiful rendition of Landslide overlaid on the second half.

I was immediately taken aback.  It sounded very reminiscent of Imogen Heap, but then again, not.  I left comments, sent tweets, and finally — while I slept last night — got an answer.

Robyn Sherwell.

I’ve never heard of Sherwell previously, but will be looking up her stuff up later today.  For the curious, here’s the straight version of her Landslide cover off her Soundcloud page:

Her stuff is available on iTunes and Amazon, and she’s on Birdland records.

Please Don’t Hack Core

Especially to neuter Core’s ability to upgrade itself.

After I published this, I had someone from cPanel reach out to have a more in depth conversation than it’s really possible to manage in a medium that caps you at 140 characters.

In the interest of transparency and context — as well as showing cPanel’s efforts thus far in working to fix things, here’s the conversation that transpired on that ticket — #6489755 on their internal ticketing system.  Any modifications on my part are purely for formatting, as well as omitting names of customer support folks.


cPanel:

Are you using the cPAddons tool within the cPanel interface to install & manage WordPress? If so, then yes, we disable the auto-update functionality within the application so the updates can be managed from the cPanel interface itself. The way our cPAddons tool tracks software is not compatible with the way WordPress updates, hence why we disable the auto-updates so we can track it through cPAddons.

If you’re not using the cPAddons tool to install/manage WordPress and have concerns of us modifying the core of the application, please let me know.

Regards,


*********** ********
Technical Support Manager
cPanel Inc.

Me:

I’m a Core Contributor to WordPress, not a cPanel User. I was speaking up on Twitter because I learned through some Forum threads that y’all were doing some very problematic things — which I’m hoping to address here.

Just to make sure we’re talking about the same thing, the three changes that I’m aware of are specifically noted are:

get_core_updates()

Short-circuited with:

# cPanel override: Disable all core updates to prevent conflict with cPAddons.
return false;

core_upgrade_preamble()

Short-circuited with:

# cPanel override: Do not display the current or the latest version, because we've disabled updates.
return;

WP_Automatic_Updater::is_disabled()

Short-circuited with:

return true; // Force this functionality to disabled because it is incompatible with cPAddons.

(Please note that all my code references to WordPress core are aimed at the latest revision of the `master` branch on GitHub)

It looks like when you’re hacking core, you’re turning off not merely Automatic Updates (as you suggested prior), but all WordPress Updates as a whole. This is a Very Bad Thing. If you were merely disabling Automatic Updates, but still leaving the user with the ability to use WordPress’s very well established upgrade system, that would be something else entirely — and in fact is documented extensively here: https://make.wordpress.org/core/2013/10/25/the-definitive-guide-to-disabling-auto-updates-in-wordpress-3-7/
— and can be done by adding a single line to your generated wp-config.php file when installing WordPress:

define( 'WP_AUTO_UPDATE_CORE', false ); # Disables all automatic core updates:

Why do you feel the need to fully disable all updates from within WordPress and force users to use either cPanel or FTP exclusively to upgrade WordPress? Why can’t they work in conjunction with one another?

Clearly, users have been dismayed and shocked when their installs haven’t been notified of security point releases that are available as y’all have killed the `get_core_updates()` function. Many don’t even realize they may need to go into cPanel to upgrade their WordPress install, and so their installation is left at an outdated, insecure version that is incredibly vulnerable to exploit.

cPanel:

 Thanks for the followup. The WordPress management through cPAddons is quite old, and very well may have been in place prior to having define( 'WP_AUTO_UPDATE_CORE', false ); within the WordPress application. I’m uncertain of that as I do not know when WP introduced that function but from Googling it the oldest result I can find is from 2012.

That said, cPanel does in fact do a few things with cPAddons in regards to customers who have out dated versions:

  • Whenever WP releases a maintenance build that addresses security concerns, we react very quickly to get our software updated to be available to customers.
  • By default, we define that software managed/installed through cPAddons is automatically updated when a new update is available.
  • Based on the above information, if the server administrator leaves the defaults enabled, once WP introduced a maintenance releases that corrects security concerns and we’ve tested and updated our source for it, customers will receive the release automatically.
  • If the server administrator decides to disable automatic software updates, the end user and systems administrator will still receive notifications that their installation is out of date accompanied with steps on how to update their application.

With that, I can definitely appreciate the concern for making it as easy and automated as possible for users to get updates for their WordPress, there’s definitely more to the situation that solely disabling WordPress’ automated updates in the core.

I’ve submitted a case (#188545) with our developers to have the logic for disabling updates changed from it’s current behavior, to using define( 'WP_AUTO_UPDATE_CORE', false );.

If you have any other questions, feedback, or concerns, please don’t hesitate to let me know.

Me:

By default, we define that software managed/installed through cPAddons is automatically updated when a new update is available.

Clearly, that’s not the case in practice. As the user who discovered this remarked:

In my audit, it appears that — of 37 total WP-based websites on our server — we have 14 that have not updated to the latest version of WordPress. Of those 14, the oldest version is 3.9 (which 3 of 14 are running), and the newest is 4.1 (which 4 of the 14 are running).

Source: https://wordpress.org/support/topic/wp-updates-not-showing-latest-wp-version-available?replies=34#post-6612888

If cPanel wants to manually update sites to current releases, I’m fully, 100% in favor of that. It’s a solid step to a safer, more reliable web.

My issue is that y’all are preventing users from updating themselves via the existing WordPress infrastructure. There’s really no reason for the blocking of an existing stable upgrade system. If you just need some way for cPanel to be notified on core upgrades, it’s relatively trivial to set up a perhaps 20 line function that will notify cPanel when it happens — and that will even account for users manually updating their WordPress installation via FTP, which your current version seems as though it would break during.

Here’s a proof of concept:

Does that make sense?

Also — I’m not a lawyer, but distributing a forked version of WordPress and still calling it WordPress (rather than cPanelPress or something) may be a trademark violation. Forking is 100% fine under the GPL for copyright on the code, but may be problematic from a trademark perspective — as what you’re distributing isn’t actually WordPress, but rather a hacked up version. If that makes sense?

cPanel:

Thank you for contacting us regarding people’s experience using WordPress as distributed via our Site Software feature. This feature is a method of installing and managing various third party applications. Applications installed via Site Software are intended to be managed entirely within Site Software, thus in-application updaters are disabled. Allowing the in-application update to proceed will cause a conflict between the updated application and the Site Software, which can easily result in confusion. From this perspective what we are doing is no different from Debian and other Linux distros that distribute applications with in-application updaters.

We generally release the latest version of WordPress within 1 to 5 days of the latest WordPress update. At minimum server administrators are informed each night of all Site Software applications that need updated. It is up to user’s to configure their notifications within cPanel to receive such updates.

Within the Site Software user interface, users are able to upgrade all applications that are out of date. In the admin interface, a server admin can choose to upgrade all Site Software applications on the entire server.

Based upon what the Drumology2001 user reported on the forum it appears something is amiss on that server. We’d love to examine that server to determine why WordPress updates were not available to the user. Based upon the fuzzy dates used on the forum, and compared with our internal records, the 4.1.1 update was available to the Site Software system prior to the initial post. We’ll reach out to him to determine whether there is anything we can do there.

I’d also like to thank you for pointing us in the direction of the various ways to manage WordPress updates (https://make.wordpress.org/core/2013/10/25/the-definitive-guide-to-disabling-auto-updates-in-wordpress-3-7/). We are currently reviewing, and discussing, these to determine which fits the Site Software distribution method the best. Using a method within the application to disable updates is usually preferred.

One of our concerns is that in-application updaters are incompatible with the Site Software distribution method. There are various things that could happen due to updating a Site Software managed application outside of Site Software. At minimum it means that from that point onward the server admin, and potentially the user, will be informed of a software update that is no longer needed. At worst someone will force an update that results in corrupting the installed application.
Handling those in a way that reduces frustration for everyone, and keeps support costs down is important to us.

Based upon the experience of the three users that posted to that thread (Drumology2001, echelonwebdesign, and sg2048) it is apparent there is room for other improvements within the system, such as update notifications. We’re taking into consideration their experience to determine how we can making WordPress hosted on a cPanel & WHM server a better experience for all.

Me:

 To summarize, my argument is largely a pragmatic one.

You can’t prevent a user from updating the software outside of the cPanel Site Software Distribution Method (gosh, that’s a mouthful, I’ll call it the CPSSDM from here on out) — as they could always just use FTP to update the software.

From a software architecture perspective, this is problematic — and it would be far simpler to develop around it so that any software updates run — whether via FTP, a remote management tool (such as ManageWP, InfiniteWP, Jetpack Manage, iThemes Sync, etc), via the WordPress Dashboard, or an Automatic Update — successfully apprises the CPSSDM of the update.

Long story short, WordPress updating itself, and the CPSSDM managing updates shouldn’t be a conflict, they should behave in concert with one another, complementing each other in their behaviors, rather than stomping across the sandbox to kick over the other’s castle.

As mentioned above, I’d be delighted to volunteer my time and expertise to help the CPSSDM have an integration that doesn’t involve hacking core files and potentially leaving users running insecure software.

cPanel:

Thanks for the follow up and summary. We both agree there are improvements to be made, as with any software – it’s never ending. We will definitely reach out directly once your expertise is needed to make sure we’re providing the absolute best experience we can to both of our customers.

Thank you again, and keep that feedback coming!


So, in then end I don’t know where things are going from here.  I know that a lot of users find it super convenient to use one click installs for WordPress, and I really hope that users who take the short-cut of one-click installs don’t wind up dead ended on an old insecure release because of some sort of server misconfiguration and hacked core files.

I’m also optimistic, because cPanel seems willing to take suggestions and input from the community on best practices.  After all — let’s face it, when they’re providing one click installs for dozens of software projects, they’re not going to be able to work with each software project individually to make sure they’re doing it the best way possible.  A lot is dependent on the communities reaching out and offering to help them do it the right way.

I look forward to hearing back from cPanel and seeing their integration done in a way that works well and plays nice with everyone else in the sandbox too.

After all, I think we all want sustainable, stable integrations — not fragile bits of code that will break if a user upgrades the wrong way. 🙂