Welcome!

AdatoSystems is committed to helping organizations leverage systems management tools to increase stability, reliability, and value.

In plain English, we:

  • Install, Improve and Integrate monitoring systems and software (Monitoring)
  • Design and Deploy websites (Web Design)
  • Automatically Backup and Update your WordPress website (SiteButler)
  • keep your “IT stuff” running with as little cost and effort as possible

A few of the amazing teams we’ve been privileged to work with can be found on our Customers Page. But the real story is what we can do for YOU.

There is nothing cookie-cutter about your organization, so our approach is anything but. We’ll find out your business goals, your technical challenges, and present you with options on how we can help.

Read More…

understand

Day 04 – Understand

Last year I discussed how some areas of technology were in (and others were out) of the range of our understanding – depending on what area of focus we have ourselves.
I still think those things are true. We need to be willing to understand, and simply prioritize based on the available time and importance.
However, a blog I read recently reminded me of an important aspect – we also need to know why.
In an essay titled, simply enough, “Why”, Derek Sivers points out that you need to understand WHY you are doing what you are doing. And the answer is not a panacea. By asking and answering “why”, certain aspects of life will become more important, and others less so.
If your goal is to be famous, then you may have to make sacrifices to family life or even money. If your goal is job stability, then career growth may take a back seat.
This is the ultimate form of understanding. It is the meta-understanding. Once you nail down the fundamental reason for your choices, you can make them faster and with more confidence that they will ultimately get you where you want to go.
Derek summarizes by saying:
“That’s why you need know why you’re doing what you’re doing. Know it in advance. Use it as your compass and optimize your life around it. Let the other goals be secondary. So when those decision moments come, you can choose the value that you already know matters most to you.”
Shakespear famously wrote “To thine own self be true”. But this is impossible unless you first take time, as Siver suggests, to really understand what you want.
puzzlebrightcropped

Day 3 – Search

As IT pro’s, we find ourselves searching for many things. We search for solutions. We search for truth (both regular and capital-T truth). Most of those things we either have a good chance of locating, as long as we’re persistent and intelligent about it.
But one of the searches that many (if not all) IT pro’s undertake is the search for the right fit in their job.
Forums, job boards, and advice columns – not to mention innumerable after-work-over-beer discussions – are filled with tales of horrific bosses, harrowing workplaces, and hideous jobs.
If there were easy answers, they’d be out there already. After 30 years, the only wisdom I can give is this: it’s the same as any other problem. You have to be persistent. You have to be smart. You have to be willing to abandon your pre-conceived notions and start over – again and again if necessary. You have to accept that the solution which worked for another person in another place may not be your solution.
And sometimes the search has to be given up for now, with the trust that you’ll take it up again another day when you are fresh and ready to try again.
library

#BlogElul 02-Act

An excerpt from an essay I wrote for an upcoming issue of “Data Center Journal” was especially relevant to today’s post. The essay is titled “Data, Information, Action”:
The saying, “you can have data without information, but you cannot have information without data,” may never have been so blindingly obvious or true as it is today. We are awash in seas of data, fed by thundering, swollen tributaries like the Internet of Things, mobile computing and social media. The goal of the so-called “big data” movement is to channel those raging rivers into meaningful insight.
For almost 20 years, my specialty within the field of IT has been systems monitoring and management. Those who share my passion for finding ever newer and more creative ways to determine when, how, and if a server went bump in the night understand that data versus information is not really a dichotomy. It’s a triad.
Of course good monitoring starts with data. Lots of it, collected regularly from a variety of devices, applications and sources across the data center. And of course transforming that data into meaningful information—charts, graphs, tables and even speedometers—that represent the current status and health of critical services is the work of the work.
But unless that information leads to action, it’s all for naught. And that, patient reader, is what this article is about—the importance of taking that extra step to turn data-driven insight into actionable behavior. What is surprising to me is how often this point is overlooked. Let me explain:
Let’s say you diligently set up your monitoring to collect hard drive data for all of your critical servers. You’re not only collecting disk size and space used, but you also pull statistics on IOPS, read errors and write errors.
That’s Data.
Now, let’s say your sophisticated and robust monitoring technology goes the extra mile, not only converting those metrics to pretty charts and graphs, but also analyzing historical data to establish baselines so that your alerts don’t just trigger when, for example, disk usage is over 90 percent, but rather, for example, when disk usage jumps 50 percent over normal for a certain time period.
That’s Information.
Now, let’s say you roll that monitoring out to all 5,000 of your critical servers and begin to “enjoy” about 375 “disk full” tickets per month.
That, sadly, is the normal state of affairs at most companies. It’s the point where, as a monitoring engineer (or, at the very least, the person in charge of the server monitoring), you begin to notice the dark looks and poorly hidden sneers from colleagues who have had “your” monitoring wake them one too many times at 2 a.m.
So, what’s missing? The answer is found in a simple question: Now what? As in, once you and the server team have hashed out the details of the disk full alert, the next thing you should do is ask, “What should we do now? What’s out next step?” In this case, it would likely involve clearing the temp directory to see if that resolves the issue.
And the next logical step from there is automation. Often, the same monitoring platform that kicks up a fuss about a server being down at 2 .m. can clear that nasty old temp directory for you. Right then and there, all while you’re still sound asleep. Then, if and only if, the problem persists, will a ticket be cut so a human can get involved. And said human will know that before their precious beauty sleep was so rudely interrupted, the temp directory had already been cleared, so it’s something just a bit more sophisticated than that.
This type of automated action is neither difficult to understand nor super complicated to establish. But in the environments where I’ve personally implemented it, the result was a whopping 70 percent reduction in disk full tickets.

#BlogElul 01-Prepare

(This post is a day late. I guess you could say I wasn’t prepared to post it during the long holiday weekend. ON the other hand, posting it then would have caught people ill-prepared to carve out the time necessary to read it.)
Preparation implies forethought, knowledge, information, capability, and (as I mentioned last year) choice (http://www.adatosystems.com/2015/08/16/blogelul-day-1-prepare/).
Prepare is wonderful. Prepare is beautiful.  In the world of IT, preparation is the work we hope we get to do every day. It is the hope we have as we drive to work.
The idea of “prepare” has an ugly underbelly though.
To borrow a concept from “Stranger Things” (https://en.wikipedia.org/wiki/Stranger_Things_(TV_series)), the “UpsideDowns” of preparation, where everything that we know and find familiar is a dark, twisted, and toxic mirror image, is “reaction”.
And THAT is a term that IT pro’s know all too well. Managers will chide us that “we’re being too reactive”. As if ignoring the system outage, network spike, or looming disk capacity issue is going to make it go away, or teach it a lesson that it needs to wait its turn.
“Let it wait” is the phrase non-IT people say without realizing it translates to “Do what *I* want now and I don’t care if the event punishes you doubly-hard later.”
So how do you avoid the demogorgon of the UpsideDown of IT?
Partly, by doing what the kids in the NetFlix show did – huddle up your posse of friends, identify the enemy for what it is, be relentless in saving each others’ butt, and rising to the challenge no matter how tired or drained you feel.
But that’s only part of the answer. The other answer is “I don’t know”. After almost 30 years in IT, I still find myself running full-tilt through horrific architecture landscapes not of my choosing, trying to evade the ravenous monster that gamely pursues me.
If there are better answers, I’m open to them. As are the comments below.

 

#BlogElul: ZeroDay

tl;dr version

A daily blog-athon running from now until Oct 3rd, with hundreds of people writing a daily post on a specific theme. You are invited to participate. I am.
Source Code
Coming up soon (the evening of Oct 2nd, to be exact) is Rosh Hashana, the Jewish New Year.
As I mentioned last year (http://www.adatosystems.com/2015/08/16/zeroday-introducing-blogelul/), between now and then is a time to reflect on how the past year went so that you can commit to making adjustments in attitude and behavior so that we continue to improve as people.
To help with that, a bunch of folks from all walks of life participate in #BlogElul: A daily writing exercise that could be a single sentence, a haiku, or an 800 word essay. Each day a single word is provided as the theme, and people take it from there.
If you missed this series last year, you’re probably thinking “Leon, this is a Jewish thing and completely outside the scope of my experience.” Yes and no.
If you have worked in IT for more than 15 minutes, you’ve probably been involved in a large development project, system rollout, or upgrade. And as the date for the big cutover approaches, there are usually daily status updates. I’m taking this opportunity to set up a standing meeting and report on my progress toward the upcoming release called “MyLife, 5777”
If you are interested in joining in you can find more information on the blog of Rabbi Phyllis Sommer, the woman who started it: http://imabima.blogspot.com/2016/08/blogelul-and-elulgram-2016.html
If you have suggestions on what I should include for any of the days, let me know!
Meanwhile, here is the word list I’ll be following:
Elul 1 (Sept. 4): Prepare
Elul 2: Act
Elul 3: Search
Elul 4: Understand
Elul 5: Accept
Elul 6: Believe
Elul 7: Choose
Elul 8: Hear
Elul 9: Observe
Elul 10: Count
Elul 11: Trust
Elul 12: Forgive
Elul 13: Remember
Elul 14: Learn
Elul 15: Change
Elul 16: Pray
Elul 17: Awaken
Elul 18: Ask
Elul 19: Judge
Elul 20: Fulfill
Elul 21: Love
Elul 22: End
Elul 23: Begin
Elul 24: Hope
Elul 25: Intend
Elul 26: Create
Elul 27: Bless
Elul 28: Give
Elul 29: Return

Respect Your Elders

This post originally appeared on SolarWinds GeekSpeak

“Oh Geez,” exclaimed the guy who sits 2 desks from me, “that thing is ancient! Why would they give him that?”

Taking the bait, I popped my head over the wall and asked “what is?”

He showed me a text message, sent to him from a buddy—an engineer (EE, actually) who worked for an oil company. My co-worker’s iPhone 6 displayed an image of a laptop we could only describe as “vintage”:

(A Toshiba Tecra 510CDT, which was cutting edge…back in 1997.)

“Wow.” I said. “Those were amazing. I worked on a ton of those. They were serious workhorses—you could practically drop one from a 4 story building and it would still work. I wanted one like nobody’s business, but I could never afford it.”

“OK, back in the day I’m sure they were great,” said my 20-something coworker dismissively. “But what the hell is he going to do with it NOW? Can it even run an OS anymore?”

I realized he was coming from a particular frame of reference that is common to all of us in I.T. Newer is better. Period. With few exceptions (COUGH-Windows M.E.-COUGH), the latest version of something—be it hardware or software—is always a step up from what came before.

While true, it leads to a frame of mind that is patently un-true: a belief that what is old is also irrelevant. Especially for I.T. Professionals, it’s a dangerous line of thought that almost always leads to un-necessary mistakes and avoidable failures.

In fact, ask any I.T. pro who’s been at it for a decade, and you’ll hear story after story:

  • When programmers used COBOL, back when dinosaurs roamed the earth, one of the fundamental techniques that were drilled into their heads was, “check your inputs.” Thinking about the latest version of exploits, be they an SSLv3 thing like ‘Poodle’, or a SQL injection, or any of a plethora of web based security problems, the fundamental flaw is the server NOT checking its inputs, for sanity.
  • How about the OSI model? Yes, we all know its required knowledge for many certification exams (and at least one IT joke). But more importantly, it was (and still is) directly relevant to basic network troubleshooting.
  • Nobody needs to know CORBA database structure anymore, right? Except that a major monitoring tool was originally developed on CORBA and that foundation has stuck. Which is why, if you try to create a folder-inside-a-folder more than 3 times, the entire system corrupts. CORBA (one of the original object-oriented databases) could only handle 3 levels of object containership.
  • Powershell can be learned without understanding the Unix/Linux command line concepts. But, it’s sure EASIER to learn if you already know how to pipe ls into grep into awk into awk so that you get a list of just the files you want, sorted by date. That technique (among other Unix/Linux concepts) was one of the original goals of Powershell.
  • Older rev’s of industrial motion-control systems used specific pin-outs on the serial port. The new USB-to-Serial cables don’t mimic those pin-outs correctly, and trying to upload a program with the new cables will render the entire system useless.

And in fact, that’s why my co-worker’s buddy was handed one of those venerable Tecra laptops. It had a standard serial port and it was preloaded with the vendor’s DOS-based ladder-logic programming utility. Nobody expected it to run Windows 10, but it fulfilled a role that modern hardware simply couldn’t have done.

It’s an interesting story, but you have to ask: aside from some interesting anecdotes and a few bizarre use-cases, does this have any relevance to our work day-today?

You bet.

We live in a world where servers, storage, and now the network is rushing toward a quantum singularity of virtualization.

And the “old-timers” in the mainframe team are laughing their butts off as they watch us run in circles, inventing new words to describe techniques they learned at the beginning of their career; making mistakes they solved decades ago; and (worst of all) dismissing everything they know as utterly irrelevant.

Think I’m exaggerating? SAN and NAS look suspiciously like DASD, just on faster hardware. Services like Azure and AWS, for all their glitz and automation, aren’t as far from rented time on a mainframe as we’d like to imagine. And when my company replaces my laptop with a fancy “appliance” that connects to Citrix VDI session, it reminds me of nothing as much as the VAX terminals I supported back in the day.

My point isn’t that I’m a techno-Ecclesiastes shouting “there is nothing new under the sun!” Or some I.T. hipster who was into the cloud before it was cool. My point is that it behooves us to remember that everything we do, and every technology we use, had its origins in something much older than 20 minutes ago.

If we take the time to understand that foundational technology we have the chance to avoid past mis-steps, leverage undocumented efficiencies built into the core of the tools, and build on ideas elegant enough to have withstood the test of time.

When, not what, defines today’s networking career

Learning new technologies is a constant challenge, but it is one that IT pros need to overcome to ensure a networking career remains relevant.

This post originally appeared on TechTarget SearchNetworking

Back in December 2014, Cisco filed a lawsuit against Arista Networks because Arista’s network device operating system, EOS, was too similar to Cisco’s beloved IOS.

This caused Tom Hollingsworth (a.k.a. “The Networking Nerd”) to speculate that this action presaged the ultimate death of the network device command-line interface (CLI).

Time will tell whether Hollingsworth is right or wrong and to what degree, but the idea intrigued me. Why would it matter if the command-line interface went away? What would be the loss?

Now, before going further, here’s a little background on me: I tend to be a “toaster” guy when it comes to technology. I don’t love my toaster or hate my toaster. I don’t proselytize the glorious features of my toaster to non-users. I just use my toaster. If it burns the toast, it’s time for a new toaster. Sure, over the years I’ve built up a body of experience that tells me my bagels tend to get stuck in the upright models, so I prefer the toaster/oven combos. But at the end of the day, it’s about making good toast.

Jeez! Now I have a craving for a panini. Where was I? Oh right, technology.

I use a lot of technologies. My phone is Android. My work laptop runs Windows 8.1. My home desktop runs Linux. My wife lives on her iPad. So on and so forth. I’ve come to believe that learning technology is like learning to play cards.

The first game you learn is new, interesting and a little confusing, but ultimately thrilling because of the world it opens up. But the second card game, that’s the hard one. You know all the rules of the first game, but now there’s this other game that completely shatters what you knew. Then you learn your third card game, and you start to see the differences and similarities. By the fifth game, you understand that the cards themselves are just a vehicle for different ways of structuring sets.

I believe that’s why people are concerned about Hollingsworth’s prediction of the death of CLI. If you only know one game — and let’s face it, CLI is an extremely comprehensive and well-known “game” — and you’ve invested a lot of time and energy learning not only the rules of that game but also its nuances and tricks, finding out that game is about to be discontinued can be distressing. But when it comes to CLI, I believe that distress is actually due to a misplaced sense of self. Because you aren’t really a CLI professional, are you?

Sure, you know a lot about CLI. But really, you’re a networking professional. Being able to configure open shortest path first (OSPF) from memory makes your job easier. But your job is knowing what OSPF is, when to use it versus enhanced interior gateway routing protocol, how to evaluate its performance and so on.

No, the concern about the death of CLI is really rooted in the fear of personal obsolescence. I’ve heard that notion repeated in conversations about the mainframe, Novell networking, WordPerfect 5.1 and dozens of other technologies that were brilliant in their time, but which, for various reasons, were superseded by something else — sometimes something else that is better, and sometimes not.

And a fear of personal obsolescence in your networking career is ultimately false, unless you are digging in your heels and choosing never to learn anything new again. (OK, that was sarcasm, folks. As IT pros, we should be committed to life-long learning. Even if you are two years away from retirement, learning new stuff is still A Good Thing™.) As long as you are open to new ideas, new techniques and yes, new systems, then you won’t become obsolete.

I’ll be honest. I think there are a lot of employers that exploit this insecurity. “Where’s a Perl script-kiddie like you going to find this kind of role?” they whisper — usually implicitly, although sometimes much more explicitly than any of us prefer. Or if we’re interviewing for a new job, they ask, “I see you have a lot of experience with AIX, but we’re a Windows shop. Do you really think your skills translate?”

I’m not here to talk about interviewing skills, salary negotiations or career improvements, so I’m not going to get into the potential responses, but I will say that the ultimate answer in each of these cases — and many others — is “Yes.” Why? Because it’s not about whether I know the fifth parameter of the gerfrinkel command in CodeMe version 12.3.9.7, which was deprecated in 12.3.9.8 in favor of the unglepacht function. It’s not about any of that. It’s about my experience on when to use certain commands, when to look for a workaround, how to manage an environment of this scale and scope and so on.

To play off the old joke about the copier repairman, a small part of your paycheck goes toward turning the screw; more of it is based on knowing which screw to turn.

As IT pros, we are paid — and are valuable — because we know how to find out which screw to turn and when to turn it. So to speak, of course.

eBooks For Your 2016 Reading List

As we tip over from the mad rush of December and prepare to ease into another year, I like to take a minute to appreciate the hush and calm that comes after the rush and bustle of various holidays.

This week after New Year I like to take a few moments to pause and regroup before diving into the new year. A chance to take stock, reflect, and think.

And so I’ve held off until now to officially promote the fruit of a few of my 2015 labors. If your resolutions for 2016 include making time to do some reading that doesn’t break your stretched-too-far-after-all-those-gifts budget, I want you to know that I’ve got a few eBook recommendations for the busy IT Pro. Each is available for Kindle (on Amazon) and also as a free PDF download.

Monitoring 101

Despite the relatively maturity of monitoring and systems management as a discrete IT discipline, I am asked – year after year and job after job – to give an overview of what monitoring is.

This book is my attempt to address that question in a more structured form, published with the assistance of the amazing folks at SolarWinds.

Intended as guide to help bring new team members (often fresh out of college or a technical program) up to speed with monitoring concepts quickly, this ebook (or portions of it) can serve as a good introduction for a variety of audiences.

Click here for the Kindle Edition | Click here for the PDF version

 

“Technically, These Are Some Random Thoughts”
Around September every year, Jews all over the world celebrate Rosh Hashana, the Jewish New Year. However, it’s not – to put it in business terms – a year-end review. It’s a job interview. the month before Rosh Hashana (called “Elul” in Hebrew) is the time for getting one’s balance sheet in order. To help with that, a bunch of folks from all walks of life participate in #BlogElul: A daily prompt provides the theme and people riff on that – sometimes a few hundred words, sometimes an image, sometimes a poem or just a single sentence. It’s something I’ve done for a few years now. I thought I’d add a twist and also do an I.T. Professional’s version of #BlogElul and post the essays on my technology-specific blog: http://www.adatosystems.com. A reflection on each of the daily prompts and what they mean in an I.T. context. You’re probably thinking “Leon, this is a Jewish thing and completely outside the scope of my experience or interest as an I.T. Professional.” To which I emphatically reply: Yes and no. If you have worked in I.T. for more than 15 minutes, you’ve likely been involved in a large development project, system roll-out, or upgrade. And as the date for the big cut-over approaches, there are usually daily status updates. Consider this the notes from my status updates before the roll-out of “TheWorld v.5776”.

Click here for the Kindle Edition | Click here for the Nook Edition | Click here for the PDF version

4 Skills to Master Your Virtual Universe

For some IT administrators, virtualization might not be a primary responsibility. Without the opportunity to learn and gain experience as part of their daily routine means these admins are getting a late start in the virtualization game. So why should IT admins, who don’t consider virtualization to be a critical part of their job description, care about virtualization? Because virtualization spans every data center construct from servers to storage to networking to security operations. Add in the fact that it is used in practically every IT shop and you have a perfect IT storm. So while you might have been hired to administer one of those systems, virtualization’s dependency and abstraction of those resources means you’ll need to bridge the
virtualization knowledge gap.

In this book, my fellow SolarWinds Head Geek Kong Yang describes the 4 key skills needed to gain mastery of your virtualized environment.

Click here for the Kindle Edition | Click here for the PDF version

 

Net Use: It’s Geek-Speak for “I Love You”

This year, SolarWinds started publishing a video series called “Geek Memories”, where the Head Geeks and other IT Professionals share flashbacks from their past, moments which defined or exemplified their geekiness and showcased a lesson that we who have made our careers in technology can relate to.

One particular memory of mind appeared recently, and I wanted to share some additional thoughts about it. You can watch the video here.

It’s no secret that I love language. I collect words and phrases the way some people collect colorful shells at the beach. I love the connection between language and culture, how one defines the other and vice-versa.

In looking back at the way “Net Use” has become a secret phrase between my wife and me, I realized this is a phenomenon that all IT Pro’s should be aware of and use to their advantage.

What I mean is that language is, first and foremost (and perhaps only?) a bridge between two parties. The golden rule of communication is not “communicate unto others as you would have them communicate to you”. Instead it is “Communicate unto others as they want (need) to be communicated to”.

Saying “Well, I prefer email, and therefore I will only use email to communicate to the other teams.” is as poor a choice as saying “Well, I prefer to speak French, and therefore I will be using French in all of my conversations.”

That idea applies to everything from the mode of communication (email, sms, face to face, phone) to the length of the conversation to your use of graphics or not. You must Know Thine Audience and tailor your information accordingly. After all, you wouldn’t ask Notepad to open and edit a Photoshop file. Don’t ask your (accounting) customer to speak fluent OSI model.

This concept also means avoiding un-necessary jargon when possible, or defining it (repeatedly if necessary) when it’s unavoidable. This is such a simple thing and yet I find IT pros who think this is tantamount to lobotomizing the entire discipline they’ve devoted years to becoming experts in. Trust me on this one – not using your favorite buzzword or acronym doesn’t make you any less of an expert. In fact, the real experts are the ones who can explain a concept, design, or plan without resorting to any specialized words. Don’t believe me? Check out “Thing Explainer: Complicated Stuff in Simple Words” by Randal Munroe (creator of XKCD) for a fantastic (if comical) example.

Recently, Seth Godin commented on the comic that inspired that same book. In that essay, Godin points out that using words, even if they exceed the 1,000 most commonly used words (or the 20,000 word vocabulary most of us have) is a one of the things that identifies us as a true professional.

I couldn’t agree more. I’m not talking about whether or not you know a word, command, programming function, etc. I’m talking about whether you can put those words into context for the listener. Can you give listener a meaningful frame of reference so that they remember the ideas you are sharing because you’ve made them relevant, have impact, and connect to their own experience?

Which brings me to my next point. The story about me and my wife and “Net Use” is cute because our experience informed the phrase with meaning. I’m not saying that you should go to work and start using arcane technical commands in place of common every day ideas (“hey boss, grep s/hungry/lunchtime/”). Instead, I believe we need to understand and appreciate how experience informs understanding. It’s not enough to give a definition of RAID1+0 or EIGRP or hybrid cloud. It’s far better to allow people to experience those things in some way and then provide the term to describe the experience they are having.

As Thomas LaRock said in an article titled “Telling Ain’t Training: How to transfer IT Skills”:

“Having knowledge is good. Sharing knowledge is better. But applying knowledge and sometimes adapting it to other scenarios is the best way to train yourself when it comes to new technologies”

That’s not always possible, but you would be surprised how many opportunities there are to link an experience to a concept and term. It is about, as professional educators say, finding ‘teachable moments’. Sometimes those moments come during a weekly department lunch-and-learn. Sometimes you can turn a routine problem ticket into a chance to say “Hey, people, check this out. I want to show you something I see all the time.” And sometimes the opportunity comes in the middle of a Sev1 emergency call. You need to take the opportunities as they present themselves.

It takes practice to find the right balance for your personality and work environment, but if you are able to do this consistently, you will find your ideas are better understood, your initiatives get more buy-in, and elusive tasks like “cross-training your coworkers” becomes infinitely easier.

After all, you are now speaking a common language.

#BlogElul Day 29: Return

RETURN is one of the most basic of all constructs in IT. Whether you are a programmer, sysadmin, network engineer, Virtualization architect, or something else, there is an almost 100% likelihood that you have needed to find out the RETURN code from one of your systems at some time in the past.

For that reason, I love that this is the last prompt for this series. It’s a way of saying “We’re all done here. Run garbage collection, write to the log files, and close this puppy down.”

It’s been a great run – by far my most successful participation in #BlogElul. Not only did I complete each and every one of the prompts this year, I did it twice – once on this blog and once on EdibleTorah.com.

For those who are long on time and short on inspiration, here’s a review of each of the essays.

Thank you for coming along on this journey with me.

RETURN 0
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

// Every good programmer leaves an easter egg or two
// Here’s where I would like to thank a few people:
// First, I am blessed beyond measure to have had the chance to marry my best friend.
// without her, I would be lost adrift in the sea of madness and chaos.
//
// Second, thank you to Phyllis Sommer (aka “Ima on (and off) the Bima”) for kicking this // event off year after year and generating both writing prompts AND enthusiasm
//
// Third, to Rabbi Raphael Davidovich. This was his first year participating in #BlogElul, and
// I tried not to ape his thoughts too much. or without attribution. But like a good partner
// at the gym or a good chevruta (sorry, CHEVRUSA) at yeshiva, his work pushed me to do
// my best as well even when I might have been more lenient with myself.