Recently, I wrote about the book, Learn to Program With Minecraft, and shared my experience getting set up to use the book with Ubuntu instead of with Windows or Mac OSX.
Yesterday I learned that the author of that book, Craig Richardson, appeared on this week’s episode of Triangulation with Leo Laporte. It’s a fun episode… they set up Leo’s Mac to run a local Minecraft server, and test out a bunch of fun stuff from the book. Well worth the watch!
Update 3/20/2016: Thanks to one of our readers, Fabrizio Fazzino, for pointing out that a software update since these instructions were prepared makes it necessary to modify them. Specifically, we’re changing how the Spigot Server component gets installed & used. I’ve updated the instructions below accordingly.
Also, he’s prepared a more succinct set of instructions that summarizes the steps. If you’re not interested in learning as much about how and why this works, I’d recommend you check my “Quick Note About Folder Structure” (in the yellow box below) and then follow his instructions.
Python is a programming language that I’ve long wanted to get acquainted with, and since she loves Minecraft so much, I felt like this book would be an ideal way for my daughter to also gain some exposure to it.
The only problem? We each use the Ubuntu distribution of Linux instead of Windows or Mac OSX.
You wouldn’t think this would be a problem: Minecraft is built in Java, which runs without a problem on Ubuntu (and many other platforms). Python is readily available for Ubuntu. Seems like a no-brainer, right?
Well… not quite. After the Amazon box arrived, I spotted this note on the back cover of the book:
The code in this book will run on Windows 7 or later, OS X 10.10 or later, or the Raspberry Pi. (See the last page for detailed requirements.)
No problem! The Raspberry Pi runs a special distribution of Linux called “Raspbian,” which is a version of Debian Linux, which is the upstream version of Linux that Ubuntu is based on. In other words: Raspbian & Ubuntu are cousins.
It seems reasonable, then, that if you can get this stuff working on the Raspberry Pi, then a much more powerful laptop running Ubuntu should be great!
Even more encouraging, there’s a nifty footnote at the bottom of Page 1 of the Learn to Program With Minecraft book which reads:
Since the book had already been out for a few weeks, this note gave me hope that perhaps some instructions for setting up all the tools on Ubuntu might’ve already been added. Unfortunately, this is not the case (yet, anyway).
So… I decided to try to do it anyway. Since author Craig Richardson and the No Starch Press team had prepared download packages for the Mac & Windows platforms, I figured that at the very worst, there would be some clues in those packages that might help me get going.
Getting Minecraft & Python Set Up On Ubuntu
First, here is a simple set of requirements (as I understand them) for you to be able to use the instructions in the Learn to Program With Minecraft book on Ubuntu:
Minecraft – this is the game itself. If you don’t already have a license for the game, you’ll need to pick one up and install it. “Installing” Minecraft for Ubuntu is quite easy: simply download the .jar file from your Mojang account and launch it. We had done this long ago, so this step was already completed for us.
Python – This is the programming language you’re learning. More on finding & installing it in a moment.
Java – while you probably have a basic interpreter (the “runtime environment”) for Java already, you’ll need the Java Development Kit to run this next tool..
Spigot Server – This is Minecraft “server” software, which you can run on the same computer that Minecraft will run on. You need this because the Python connection to Minecraft relies on a server plugin that you can’t just run with your plain old Minecraft installation.
Minecraft Python API (py3minepi) – It turns out that this connection between Python and Minecraft was originally developed especially for the Raspberry Pi. The way I understand it, this tool is an API for Minecraft that works with Python. You need it.
Raspberry Juice Some brave souls created Raspberry Juice as a way to run the Python/Minecraft connection on other platforms (not just the Raspberry Pi). When you follow the instructions in the book for Windows or Mac, this little gem is bundled in. But if you’re installing from scratch for Ubuntu, you’ll need to get it yourself. Not realizing this, I installed all the other tools and ran into a really nasty error that I couldn’t get around:
This error message was the part of the installation that was trickiest to resolve, but after a bit of digging, I was able to work it out.
The detailed instructions for each of these items follows (below). The one note I’d like to insert here is this:
I’m using Ubuntu 14.04 LTS, so your installation steps may vary somewhat if you’re using a different Ubuntu version.
Installing Python 3
You actually need 3 separate items that fall under the Python 3 heading:
Python 3 (the programming language itself)
IDLE (the development environment for Python, a/k/a the place where you’ll type commands and write programs)
PIP (the “package manager” for Python). You need this to install
For packages that are developed for Ubuntu, I tend to prefer using the “Ubuntu Software Center” to install stuff like this.
The only “gotcha” with Python is that there are a number of software versions and tools and so forth. So… launch the Software Center and search “python3” (with no space).
You should see a listing that says something like, “Interactive high-level object-oriented language (default python3 version)”
That’s the one you want. Do yourself a favor and click on “more info” so you can check the box for “IDLE 3” while you’re at it.
Install those, then run a similar search for “python3-pip” so you can use the package manager.
Prefer the command line to the Software Center?
Here are the commands to get python installed if you’d rather do this than use the Software Center. You’ll need to open a terminal to run these:
From the Ubuntu Software Center, just search “openjdk-7” and look for the “headless” option (this is lighter weight because it doesn’t include a GUI).
Or from the terminal:
sudo apt-get install openjdk-7-jre-headless
Installing Spigot Server
Update 3/20/2016 As I mentioned in the update at the top of this post, Spigot Server has released a new version: 1.9. Since the other components we’re using have not yet (as of today) updated to accommodate this, you’ll need to make sure that you download Spigot 1.8.8 and use it even though it is not the most recent version available.
Spigot is one of the most popular Minecraft server options, and is a necessary component in order to get Python & Minecraft talking to each other.
Getting the server software up & running is a matter of compiling the latest version. This reference page from the Spigot wiki is the one I used, and it seems to stay up to date. However, since it contains the instructions for multiple platforms, I’ll endeavor to simplify here.
One item to install first that will make this simpler is git. You’re going to need a terminal window anyway, so I’d recommend going ahead and opening it now and running this command to install git:
To help make things easier on yourself, you might find it useful to use a somewhat similar folder structure to the one described in Learn to Program with Minecraft for the Windows & Mac users.
To accomplish this for myself, I opened the “Files” application and browsed to my “Documents” folder, then created a new folder called “MinecraftPython”, then inside that folder another called “MinecraftTools”.
I recommend moving the BuildTools.jar file that you just downloaded into that “MinecraftTools” folder.
To do this, you have a few options:
You can drag and drop using 2 “Files” windows, or
you can cut & paste if you just have one of those windows open.
Otherwise, you can move the file from the command line in a Terminal window with something like: mv ./Downloads/BuildTools.jar ./Documents/MinecraftPython/MinecraftTools/BuildTools.jar. Of course, you’ll need to modify that command to suit your particular situation (if you’re using a different folder structure or starting from a different location in your Terminal window than I did, for example).
Once that’s done, from your Terminal window, you’ll need to change directories to the location of your BuildTools.jar file. Depending upon where you’re starting from, that might mean a command that looks something like: cd ./Documents/MinecraftPython/MinecraftTools.
Then you’ll want to execute these 2 commands:
git config --global --unset core.autocrlf
java -jar BuildTools.jar This needs to be tweaked to make sure you use version 1.8.8 of the Spigot Server component (for now).
java -jar BuildTools.jar --rev 1.8.8
This will get the Spigot Server built. In order to finish installing, creating a startup script will be helpful. You can create one with gedit by running a command like this:
The gedit text editor will open. Copy and paste this into the editor:
Note: the filename “spigot-1.8.8.jar” was the current filename as of this writing. You’ll need to confirm that filename based upon your build, and edit the command here if it’s different use that filename as is for now (until the other components are updated to accommodate newer versions of Spigot server). Also, the Spigot instructions specifically note that the ‘MaxPermSize’ directive is no longer needed or supported in Java 8, but since I’m using Java 7, I left it in mine.
Save the file and close gedit.
Next, you’ll need to make the script executable. From the same terminal window, type:
chmod +x start.sh
Before you launch this file, you’ll need to accept the End User License Agreement. Locate the eula.txt file in your “MinecraftTools” folder and open it for editing. You can do this from a terminal window by typing gedit eula.txt . From the “Files” application, you can right-click the eula.txt file and choose the option to edit it with gedit.
Before you change the line that reads eula=false to eula=true, you’ll want to review the Minecraft End User License Agreement and verify that you’re ready to agree to its terms. Once you are, changing the value to “true” and saving the file will allow you to launch the Spigot Server without a hiccup (assuming that it is installed correctly).
Starting Your Spigot Server
Once that’s completed, you can start the Spigot Server to ensure it’s working properly. You’ll use this same command start the server each time you need to use it:
If all has gone according to plan, you should see the output of the server startup process in your terminal window. The Spigot Server will create a new Minecraft world as it launches, and once it’s up and running, you’ll see a > prompt with a flashing cursor next to it. You need to keep this window open.
Testing Your Spigot Server Installation
To test your server, launch Minecraft as usual.
Click “Multiplayer” and then choose “Add Server”
Give your new local server a name. The book recommends Minecraft Python World for it. In the “Address” box, type localhost. There’s a picture at the top of page 17 of the book which you can refer to as an example.
Quick note: if you’re using a typical Minecraft installation, then your Minecraft version will have updated by now to a version newer than the Spigot Server version. If so, you’ll need to edit your “Profile” and specify the Minecraft version to run so that it matches your Spigot Server version (1.8.8 if you’re following this writing exactly). Alternatively, you can create a new profile instead (this is what I chose to do) so that your main Minecraft profile continues to use the latest Minecraft version.
You can double-click the Minecraft Python World and check out your new world.
Note:The author’s downloads for Mac & Windows operating systems are pre-configured to be in Creative Mode. This world will be in Survival Mode instead. This can be changed by editing the server.properties file in your “MinecraftTools” folder and changing the line that reads gamemode=0 to gamemode=1 . You may also find that you need to change the line that reads force-gamemode=false to force-gamemode=true .
Play as long as you like, but before proceeding: you’ll want to stop the Spigot Server. In the window with the flashing cursor, simply type stop at the > prompt, and the Spigot Server will save everything and shut itself down.
Installing the Minecraft Python API
Next, you’ll need the Minecraft Python API. There’s a Github repository here:
I recommend just hitting the “Download Zip” button there. The file will be saved to your “Downloads” folder. You’ll want to extract the .zip file’s contents. You’ll end up with a folder called py3minepi-master, which we need to copy into the “Documents/MinecraftPython/MinecraftTools/” folder.
Once the folder has been relocated to the “MinecraftTools” folder, we need to run a command to install it. From your terminal window (assuming your current directory is still the “MinecraftTools” folder), type:
sudo pip3 install ./py3minepi-master
Installing Raspberry Juice
The last piece, I believe, is the actual Raspberry Juice plugin for Spigot. You can find it on the project’s home page:
Look for the “Recent Files” link on the right. As of this writing, the latest was RaspberryJuice v1.7 for 1.8.1. Follow the links, and eventually, you’ll end up with a .jar file.
This file needs to be copied into the “plugins” folder of your Spigot Server installation. If you’re following the directions here specifically, then you’ll find that folder at “/Documents/MinecraftPython/MinecraftTools/plugins”
Put the .jar file in that folder. Your Spigot Server will automatically find it the next time it starts up.
Time to Test!
If all has gone well, you should be ready for the “Getting to Know IDLE” section of the setup instructions on Page 20 of the book. If you’re able to successfully run the tests there, you’ve got everything set up correctly!
It was at this stage that I got that nasty error I mentioned earlier:
When I got the “connection refused” error, I did a bunch of searching, but nothing seemed to fit. Ultimately, I hunted down the port number that the “minecraft.py” script was trying to connect to (port 4711). This didn’t make any sense, because the Minecraft server software defaults to port 25565. Searching around for information about what might be running (or not running, in my case) on port 4711 was what yielded the information about the Minecraft Python API.
Thankfully, author Craig Richardson left some clues for us in the pre-packaged downloads he made available for Windows & OSX. On my Ubuntu system, I opened up the download he prepared for OSX (since OSX and Linux are more or less cousins, I figured it would be worth a shot) and found Raspberry Juice. It was perhaps the least obvious component of this whole setup.
So far, this setup has been working for me. I’m not 100% certain that I haven’t missed something, but if I have, then it doesn’t appear to be affecting things so far.
I hope you find this helpful! Let me know what you run into in the comments. I’ll do my best to help!
My wonderful, gorgeous wife, Jill, and I arrived on campus at Florida International University for day 2 of WordCamp Miami 2016… just in time to enjoy another round of bagels & coffee from Einstein Brothers Bagels.
After the opening remarks, we got our dose of Cain & Obenland in the Morning, which was a riot.
Their final segment on WordPress news was fun. Some of the tidbits they shared about what’s happening with WordPress Core were exciting, including the fact that we’ll soon be saying goodbye to the “Bleak Screen of Sadness™”
Jill and I stayed together for the first session of the morning, and we caught “Bootstrapping Your WordPress Business – Going from 0 to 10 Employees” with Scott Mann, who runs Highforge, an agency in Central Florida. Scott started with a compelling story about smoke jumper Wagner “Wag” Dodge and a famous firefighting incident at Mann Gulch which resulted in an on-the-spot innovation that continues to be used by firefighters today.
The point: when you’re bootstrapping your business, you’ll probably need to keep replacing your straps, because they’re going to get burned off!
Scott’s session ran the gamut from tools you can use as you bootstrap to finding and hiring the right talent and even when and how to raise your rates. Very practical. If you own a business and you’re bootstrapping and trying to grow, check out his slides or catch the replay if you can.
Next, Jill headed off to the “All Users” track, and I stuck around for “Product Marketing Tips for Commercial Plugins” with Chris Lema. While he was specifically focused on developers who are selling premium WordPress plugins, his actual talk contained a ton of useful tactics for any business.
The Business track that the organizers put together for today has turned out to be utterly fantastic.
We planned to divide & conquer, but ended up both catching the session “How to Keep a Client Happy” by Christina Siegler on the Content & Design track.
After that session, I snuck over to the Development track to hear a couple of more technical sessions, and Jill stayed for more Content & Design goodness. She spoke very highly of the session with Michelle Schulp on “Becoming The Client Your Developer Loves”—so much so that I’m planning to catch the recording.
In “Writing Multilingual Plugins and Themes,” John Bloch didn’t shy away from tech issues, and he dug right into code samples while explaining the concepts around internationalization (“I18N” for short).
Then I caught Chris Wiegman, whom I’ve gotten somewhat acquainted with since he relocated to paradise Sarasota a little over a year ago. He’s known as an expert in WordPress security, and his “Application Security For WordPress Developers” was entertaining, informative, and thorough… not to mention somewhat over my head in spots.
On my way to the Development track, I bumped into Pam Blizzard, one of the organizers of the WordPress community in Sarasota.
I’ll try to come back and fill in more about our experience as time permits!
There was an authentic, vulnerable talk on getting the most out of the WordPress community from Marc Gratch. He shared some very personal experiences (that I’m sure many of us can identify with) about working alone & working remotely, and how the amazing WordPress community can be a great support system.
His “give more than you get” approach was fantastic, and true to form, he gave a great of resources he’s built over time:
Then a fast-paced session on building a 6-figure email list with Syed Balkhi, creator of Opt-In Monster, WPBeginner, and many other sites & tools.
Then I caught up with Jill and we got some great lessons from Dr. Anthony Miyazaki about what is an acceptable number of times to dip your chip into the guacamole. He showed how you have to plan ahead so that you have enough of your chip left to really maximize your dip.
One of the serious considerations of our time is the need to store and have reasonably usable access to all the digital media we are creating.
How often do we snap a photo and upload straight from our mobile devices to services like Instagram and Facebook?
How easy is it, using the apps on our phones, to bang out a tweet or a status update?
But have you ever given any thought to what might happen if those sites disappeared? How much of your personal life is recorded there?
Consider my own situation.
I joined Facebook in 2008, coming up on 8 years ago now, and have had countless meaningful interactions there with people I care about (let’s set aside all the less meaningful interactions for the moment).
In that time, I’ve been through maybe 6 or 7 smartphones. I’ve snapped thousands of photos, many of which I have no idea where to find at the moment*, but some of which I have uploaded to sites like Facebook, Twitter, and various iterations of what is now Google Photos.
Unlike in decades past, today we simply don’t “print” the photos we take (I can’t think of a good reason why I would, frankly), but this means that we also don’t give much consideration to what happens to those photos—not to mention our personal interactions and communications, and even stuff we upload to the web or social networks—after the fact.
I don’t purport to have all the answers. In fact, my purposes in writing this post today are more around sparking some thought rather than speaking to specific solutions, which almost certainly will vary from person to person.
But if you treat your social media profiles like a de facto backup of some of your most treasured photos (like I have), and you’ve had meaningful interactions with others on social networks (like I have), then an important question needs to be raised:
What would you lose if one or more of these sites were to shut down?
This week, I spent a fair amount of time getting better acquainted with some of the principles established by the #Indieweb community. This is a group of people committed to the creation and viability of the “open web.”
The terminology around the “open web” is used to draw a distinction between the web that can and should be created and used by individuals, as opposed to the “corporate web,” which is centered around commercially driven services.
One of the goals of the movement is to keep the web open and free. This doesn’t exclude the usage of paid services—on the contrary, it’s clear that even users of the open web will need to pay for services like domain registration and web hosting (although there are, as I discovered this week, more free options for those items than I would’ve guessed).
In fact, the distinction between the “free and open” web and the “corporate” web isn’t so much one of payment, but rather of ownership, access to, and control over one’s own data.
To illustrate this, IndieWebCamp, one of the groups central to the #IndieWeb movement, maintains a list of “site deaths,” which are often free (but not always) services for users to write blogs and upload/store/share photos, among other things, but which have famously shut down over the years. Often, this leaves users with little or no opportunity to download the data they’ve stored on these services.
Examples? When Geocities shut down in 2009, something like 23 million pages disappeared from the web. Previously, AOL killed off AOL Hometown, removing more than 14 million sites from the web. Google has killed off a number of products, including Google Buzz, Google Reader (which personally affected me), Google Wave, and countless others.
In many cases, users had even paid for the services, but due to a variety of factors, such as:
lack of profitability
changes in ownership
shifts in direction, and even
loss of interest on the part of the owner(s)
…the services get shut down anyway.
There are a couple of tragic ramifications of these site deaths.
One is that often the people most harmed are the ones least knowledgeable about setting up and maintaining their own web presence.
Often the appeal of a free or inexpensive blogging platform (for example) is that one doesn’t need to gain any real know-how in order to use it.
While that’s great in terms of getting people to get started publishing on the web or otherwise using the web (which I’m certainly in favor of), it has often ultimately sucker-punched them by never creating an incentive (until it’s too late, of course) to gain the minimal amount of knowledge and experience they would need to maintain something for themselves.
Even when the users are given the opportunity to download their data, which is not always the case, these are the very people least likely to know how to make use of what they’ve downloaded.
Another tragic loss is for the web community at large. When a service of any significant size shuts down, often this results in the loss of tremendous amounts of information. Vanishing URLs means broken links throughout the parts of the web that remain, which makes the web less useful and more costly to maintain for us all.
Some of what is lost is of more value to the individuals that originally uploaded or published it than to the rest of us, of course. But even personal diaries and blogs that are not widely read contribute to our large-scale understanding of the zeitgeist of the times in which they were created, and that is something that could be preserved, and for which there is value to us from a societal perspective.
Geocities, as an example, has accurately been described as a veritable time capsule of the web as it was in the mid-1990s.
Maintaining Our Freedoms
At the risk of being accused of philosophizing here, I’d like to step away from the pragmatic considerations around the risk of losing content we’ve uploaded, and look for a moment at a more fundamental risk of loss: our freedom of speech.
The more we concentrate our online speech in “silos” controlled by others, the more risk we face that our freedoms will be suppressed.
It’s a simple truth that centralization tends toward control.
Consider this: according to Time, as of mid-2015 that American Facebook users spend nearly 40 minutes per day on the site.
According to a study published in April, 2015, a team of researchers found that the majority of Facebook users were not aware that their news feed was being filtered and controlled by Facebook. (More on this here.)
As a marketer, I’ve understood for many years that as a practical consideration, Facebook must have an algorithm in order to provide users with a decent experience.
But the question is, would Facebook ever intentionally manipulate that experience in order to engineer a particular outcome?
So… we’re spending an enormous amount of our time in an environment where most of the participants are unaware that what they see has been engineered for them. Furthermore, the audience for the content they post to the site is also then being manipulated.
Let me emphasize that it’s clear (to me, at least) that Facebook has to use an algorithm in order to provide the experience to their users that keeps them coming back every day. Most users don’t realize that a real-time feed of all the content published by the other Facebook users they’ve friended and followed, combined with content published by Pages they’ve liked, would actually be unenjoyable, if not entirely unusable.
But the logical consequence of this is that a single point of control has been created. Whether for good or for ill—or for completely benign purposes—control over who sees what we post exists. Furthermore, anyone is at risk of having their account shut down for violating (knowingly or unknowingly, intentionally or otherwise) a constantly-changing, complex terms of service.
So… even if you aren’t concerned about a service like Facebook shutting down, there remains the distinct possibility that you risk losing the content you’ve shared there anyway.
In other words, someone else controls—and may, in fact, own—what you’ve posted online.
What Can We Do?
All of this has strengthened my resolve to be committed to the practice of owning and maintaining my own data. It isn’t that I won’t use any commercial services or even the “silos” (like Facebook and Twitter) that are used by larger numbers of people, it’s just that I’m going to make an intentional effort to—where possible—use the principles adopted by the IndieWeb community and others in order to make sure that I create and maintain my own copies of the content I create and upload.
There are 2 principal means of carrying out this effort. One is POSSE: Publish on your Own Site, Syndicate Everywhere (or Elsewhere). This means that I’ll use platforms like Known in order to create content like Tweets and Facebook statuses, as often as practical, and then allow the content to be syndicated from there to Twitter and Facebook. I began tinkering with Known more than a year ago on the site social.thedavidjohnson.com.
As an example, here is a tweet I published recently about this very topic:
Spending some time this week getting better acquainted with the #indiewebcamp community. Lots to learn!
While it looks like any other tweet, the content actually originated here, where my personal archive of the content and the interactions is being permanently maintained. This works for Facebook, as well.
I’m making the decision now to gradually shift the bulk of my publishing on social networks to that site, which will mean sacrificing some convenience, as I’ll have to phase out some tools that I currently use to help me maintain a steady stream of tweets.
The payoff is that I’ll have my own permanent archive of my content.
In the event that I’m not able to find suitable ways to POSSE, I will begin to utilize the PESOS model: Publish Elsewhere, Syndicate to your Own Site.
Since some of the silos that I use don’t permit federation or syndication from other platforms, I’ll be pulling that content from the silo(s) in question back to my own site. An example is Instagram, for which inbound federation is currently difficult, but for which outbound syndication (back to my own site) isachievable.
Not as Hard as it Sounds
I am, admittedly, a geek. This makes me a bit more technically savvy than some people.
But… the truth of the matter is that this really isn’t hard to set up. The IndieWebCamp website provides an enormous wealth of information to help you get started using the principles of the IndieWeb community.
And it can begin with something as simple as grabbing a personal domain name and setting up a simple WordPress site, where if you use the self-hosted version I’ve linked to, you’ll have the ability to publish and syndicate your content using some simple plugins. Alternatively, you could use Known, which has POSSE capabilities (and many others) baked right in.
There are loads of resources on the web to help you take steps toward owning and controlling your own data.
Note: For those who live in or around Sarasota, if there’s enough interest, I’d be open to starting a local group (perhaps something of a Homebrew Website Club), to help facilitate getting people started on this journey. Respond in the comments below or hit me up on Twitter if you’re interested.
Personal Note of Gratitude
I’m indebted to a long series of leaders who have worked to create the open web and have personally influenced me over a number of years to get to where I am today in my thinking. There are many, but I’d like to personally thank a few who have had a greater direct impact on me personally. They are:
Matt Mullenweg, co-founder of WordPress. Matt helped me understand the important role of open source software, and although he didn’t invent the phrase, he personally (through his writings) introduced me to the idea of “free as in speech, not free as in beer.”
Kevin Marks, advocate for the open web whose tech career includes many of the giants (e.g. Google, Apple, Salesforce, and more). Kevin understands the technology, the ethical and societal implications of factors effecting the open web, and has taken on the responsibility of serving as a leader in many ways, including in the IndieWeb community.
Ben Werdmuller, co-founder of Known. Ben and his co-founder, Erin Jo Richey, have also stepped up as leaders, not only creating technology, but endeavoring to live out the principles of the open web.
Leo Laporte, founder of TWiT. As a broadcaster, podcaster, and tech journalist, Leo was instrumental in introducing me to people like Kevin Marks and Ben Werdmuller by creating and providing a platform for concepts like these to be discussed.
As I said, there are plenty more I could mention. In today’s world of the internet, we all owe an incredible debt of gratitude to many who have worked tirelessly and often selflessly to create one of the greatest platforms for free speech in all of history. Their legacy is invaluable, but is now entrusted to us.
Let’s not screw it up.
*I’ve got most of them. They’re stored on a series of hard drives and are largely uncatalogued and cumbersome to access. Obviously, I need to do something about that.
If you are a blogger, influencer or other paid endorser (including someone who receives free products, incentives or “in kind” compensation), you’ll definitely want to review them.
If your company sends products or other compensation to bloggers, social media influencers, or other paid endorsers, it’ll also be worth reviewing—you may have responsibilities where educating or monitoring your influencers are concerned.
So… working as a consultant who does a great deal of writing, training, and research online, I sit at my desk a lot more than I’d like to admit.
I’ve had great advice some phenomenal people in my life, especially my chiropractor, about how to sit (or really how not to sit), and thankfully, I’ve made some ergonomic adjustments.
But the fact remains that I sit far too much, I stand up far too little, and my posture as I work is still not too great.
[And as an aside: that’s most definitely not me in the picture accompanying this post. My desk is nowhere near that clean. And I’m usually not in a suit when I sit at it. But I chose the picture just because his posture will make my chiropractor physically ill.]
So, I was thrilled to learn that one of our clients, whom my wife & I actually consider a friend as well, has completed significant training and is now certified in the MELT Method. We’ve worked with her a great deal in the past, and benefited from her expertise in STOTT PILATES® and Applied Functional Science®, among other things. And given her propensity for extensive research, I was not surprised that she had hunted down the solution to her own chronic pain problems (hers were, alas, caused by overuse as opposed to underuse, which was more likely the cause of mine).
In any case, I think we’ll plan to attend some workshops and get better acquainted with MELT, but in our little “preview” session with her, Shannon gave us an understanding of some of the basics, and it was remarkable the degree to which we experienced results in just a few minutes. More to come on this one!