Tag Archives: devops

Engineering the future backwards.

I’ll be the first to admit, I’m probably butchering the crap out of what Cognitive Edge put into the “Future backwards” methodology but in butchering the crap out of it, I’ve learned it can be a great vehicle to visualize work but also bridge the communications gap and provide a way to represent emergence, failure, successes, convergence or simply clarify overwhelming decision points.

From Coginitive-edge.comThe Future, Backwards method was created to aid in widening the range of perspectives a group of people can take on understanding their past and the possibilities of their future. The entrained perspectives of people within an organization give them a limited view of the present, and such entrained patterns of past perception can determine its future.

I use the idea of building a future backwards diagram to achieve multiple goals. For me, it helps represent a map of more simple decisions or states and how those states appear to flow from historical perspectives to future perspectives (I try and visualize these forwards and backwards in time and sometimes representative of the decision points made now). Not only to represent as things were, as things are but as things may be and how decision points can lead to future states, surface emergent properties, show how systems adapt & evolve or how things fall back and fade away.

What I love about the ideas behind this future backwards mapping is that it is a visual representation of a complex “thing”. In my talk referenced below I tried to convey that a pterodactyl was misunderstood for YEARS but by visualizing it people were able to convey lessons learned and morph their understanding into a more complete understanding – a pile of bones is simply to incomprehensible of a place to be at to decide what something really is.

Even though this pterodactyl was wrong, it still led to a better understanding of it.


As for the following diagram that looks like a twisted paperclip – that is a Feynman diagram – a picture that conveyed a very complex interaction of subatomic particles that simplified calculation into manageable chunks and conveyed a way for people to communicate very complex and abstract things.


So what is “Future Backwards”?

The future backwards is a method of “sense making” designed/created by cognitive-edge. From Wikipedia “Sensemaking is the process by which people give meaning to experience. While this process has been studied by other disciplines under other names for centuries, the term “sensemaking” has primarily marked three distinct but related research areas since the 1970s: Sensemaking was introduced to Human‚Äďcomputer interaction by PARC researchers Russell, Stefik, Pirolli and Card in 1993, to information science by Brenda Dervin, and to organizational studies by Karl Weick.http://en.wikipedia.org/wiki/Sensemaking

Most of all for *ME* – its a diagram of something complex that I can apply a little science to in order to better understand, measure and predict from.

My Butchered Future-Backwards diagram – Getting Started


Again, this example image is completely my take on future-backwards and how I’ve used it to make sense of my work. I’ve used it to show an example “Desired” or “future state” and I’ve used it to show our “current state” and then a “concerned state”. The example current state is not positive or negative but the reality of what is driving the business. (nor is this really the objective of the process as described by cognitive edge)

In some cases mapping this out can help you reinforce what you need to succeed. If you need to “keep the lights on” that “current state” may be the most important thing. This was one of the most important things I let escape my mind in my talk about simple diagrams such as this – the visualization of complex parts & decisions that are often lost in translation as teams are making huge leaps into new territory almost as an act of faith rather than a testable hypothesis of “will this work and how can we know”. You may see that you need to distribute work – hand off the “keep the lights on” to an “SRE” team but move the “future” state to an engineering team that can have the focus, budget and resources needed to sustain apparent states.


When you map our a “Future backwards” diagram you have done some work on visualizing your work and through these representations you can simplify the calculations and more importantly the communications of what works, what didn’t work and what may have worked better or worse than you expected. You can see if decisions lead to alternate paths or if systems/processes you thought would diminish were actually surfaced and expanded. This process of comparing and looking for variance is how I see adaption, exaptation or even extinction. It’s where I “borrow” another method of setting up some of these decisions / states as “safe to fail” experimentations just to know if they’re viable and surfacing or buffering desired or undesired states & outcomes.

Adaptation / Exaptation

By visualizing your future backwards, you may see patterns that surface all the time or patterns that seem to evolve to always survive even in states you didn’t predict them to be. This is hard to quantify unless you’re mapping them out and you may never recognize such value or in some cases, patterns of failure unless you *do* map it out. Some things can be so well entrenched that you may need to represent them in a future-backwards diagram in much finer granularity than the broad-stroke decision graphs i’ve shown in my examples.

In this example future-backwards map I broke things out a bit more specific to a use case and showed how its less a concern of good/bad/status quote but more a realization of containers, physical machines or virtual machines and possible divergence & convergence routes between the paths.


In the above example a Java shop may choose to do design choices of all of the above or one or the other and you can visualize this to show how two decisions may be similar enough that they converge and the others may be divergent.

I could cite examples all day long, but I just wanted to give more breadth to my talk to try and answer some of the questions that came up and whatever I missed in my 5 minute ignite ūüôā

A Lightning talk is a darn near impossibility on this topic, but I hope to one day master it because I think 5 minutes of future-backwards has a payback impossible to to quantify to those who embrace it and butcher it for their own way to improve communications & awareness. Here is my deck from DevOpsDays Austin 2015.

BTW, these diagrams are super simple to make if you have a modern wiki or website/editor with the “gliffy” plugin. Just use the standdard basic shapes and lots of decision triangles. It really only takes a few minutes to do but the payoff can be massive.

I look forward to hearing you’re use of such diagrams and what success/thoughts or feedback you get. (or if it fails, I want to hear that too..)

PS, I apologize @snowded if I’ve butchered your hard work, but it has inspired me to do awesome things, so take that for whatever it’s worth ūüėÄ

This is just a way to get you thinking and visualizing. Some people like to do super complex overall “Design sessions” and leave this stuff up to management but as a tech person who works with data, graphs and visualizations all day long it just made sense to bridge this gap not only as finding intent/design in my work but communicating it and formalizing it.

Best of all, when you draw this stuff up and put it up on a wiki, go back to it later and see if what you experience “jives” and make sure to discuss and map what worked/didn’t work to better understand and “make sense” of your own environment. BTW, Adaptation and Exaptation are wonderful things, you can really empower people when you see and foster their creative output and translate that or surface that through future states and its also pretty amazing when something created with different intent can be represented as having value even in places you didn’t expect them to be!

Map/draw/graph on!

Tagged , ,

#DOES14 Conference Notes

DevOps is a thing in the Enterprise and DevOps Enterprise Summit #DOES14 certainly made the case showing organizations such as Disney, GE, Target and groups within the US Government working on DevOps styled initiatives.

I got home super late and i’m super drained from too much allergy/sinus meds but I wanted to share some thoughts here and express my enthusiasm and gratitude for such a fantastic event. ¬†Expect more soon, but a quick summary follows:

Common aspects of DevOps in the enterprise:

Agile РLots of Agile transformations and Agile team development. Seemed to be one of the most consistent messages that enterprises feel the need to adopt Agile methodologies to achieve DevOps goals.

Tools¬†– Enterprises¬†aren’t just doing unit tests and artifact management through¬†¬†CI / CD systems but they’re using them to solve challenges such as code reviews, security, audit, compliance, ¬†risk analysis, security analysis and much more. I was excited to see so much discussion on this topic not just from a developer /operations perspective but how management and auditors see opportunity to drive value here as well.

Case Studies – If you needed/wanted case studies, you simply should have been here. Be sure to watch the #DOES14 website and youtube for release of speaker decks and Videos.

Some common concerns that stuck out were definitely:

User Acceptance Testing – This issue was almost universal regardless if your app is in house or a commercial off the shelf system (COTS) – now that you can empower your development and operations team to automate much of the grunt work of CI / CD and development testing the “UAT” part of QA is still very manual & hands on setting the takt time for your entire organization.

Audits – Lots of concerns/questions on Audit. There may need to be an entire day track to cover the issues of Enterprise Audits. ¬†Maybe next year? We didn’t even scratch the surface on this topic and yet, it was an open question with so many speakers and attendees curious as to what others do here.

Personal Thoughts:

To be honest, I was impressed with the depth and breadth that some of these organizations have adopted Lean / Agile and DevOps values.  If Gene Kim accomplished anything with this conference it was making a bold statement that DevOps is in the Enterprise and backing that up with three days of solid evidence for that.

One thing I hope to see next year is how more organizations derive the value and do value stream mapping. I love the enthusiasm and love seeing what people have done but sometimes I felt people were too enthusiastic about trying to do “DevOps” to be like others that do “DevOps” and spend so much to measure how they compare against others in that regard. I’m not sure that this competitive notion of who can DevOp better than everyone else is wrong per se, but I do feel sometimes people do things to lead an idea more than they do things to solve problems. ¬†A local optimization gone mad¬†if you will ūüėČ ¬† (In a way I have a fear of Applied DevOps.. ¬†hehe)

I’m still recovering and getting all of my notes together. If you have any specific questions/comments or if you were at the conference and want to discuss particular topics, get in touch! ¬†More posts to come, especially when¬†I can link in videos / slides to share as they get released/published!

Edit:  Update at 3:18 PM РWe discussed the conference a bit on HangOps this afternoon.  Feel free to watch the discussion on YouTube below!

Tagged , , ,

DevOps in the Enterprise – Oracle Financials

This post is more of an introduction to a journey of sorts to get thinking about DevOps in an Oracle eBusiness (Financials/CRM) type infrastructure and I plan on developing these posts over time with more details; incorporating feedback on the goal, designs, components and concerns and just as importantly, I hope to collaborate on these ideas to incorporate non Oracle tools.¬† It’s extremely important (at least to me!) to leverage the existing tools whenever and however possible so that Oracle doesn’t remain a perpetual silo no one else wants to touch!

Back story about me: I started out supporting Oracle eBusiness Suite in the late 90s, running 10.7 NCA, 11.0.3, every release of 11.5.x and currently supporting a 12.1 environment while trying to plan ahead to R12.2.¬† I’ve supported Oracle eBusiness on AIX, HPUX, Linux, Windows and Solaris environments over the years – through custom processes, oracle best practices to integrating with ITIL tools (Mercury Interactive at the time). I even spent a while working for Oracle themselves supporting implementations for higher education & healthcare verticals. I’ve seen it, I’ve done it, I’ve broken it, I’ve fixed it, and I have a lot of stories to share about it ūüôā

Lets get the wheels spinning!


Achieve a process of continuous integration (or more aptly “continuous validation”) within the eBusiness suite platform to achieve DevOps value objectives.

Concerns: (a few of many..)

Just how do you do DevOps with eBusiness suite (and similar COTS systems)?

  • How do you unit test?
  • How do you load test?
  • Do you push code to production?
  • How do you provide developers access?
  • What does the process look and feel like?
  • What about Business Analysts?
  • Audits?
  • Performance?
  • Availability?
  • feedback loops!


The components I use to build my “Enterprise Devops Pattern” for eBusiness Suite.

  • Oracle eBusiness Suite
  • Oracle RDBMS
  • Oracle iAS/Weblogic
  • Oracle Application Testing Suite
  • Oracle Cloud Control
  • Oracle Linux
  • Puppet, PuppetDB & Foreman
  • VMware


What are the common processes we can leverage, optimize and built trust upon to greatly reduce  systems complexity?

  • Patching
  • Project work
  • Customizations
  • Cloning
  • Automation
  • Interfaces
  • Integrations
  • ….

Putting it together

How do we build a system that embraces trust, is reliable and performant? How do we test and prove our value stream?

  • Measuring
  • Experimenting
  • Audit defense
  • Monitoring.. testing..
  • Feedback loops
  • Reporting..

As you can see, just by starting to list out bullet points, the complexity of the eBusiness suite starts to rear its ugly head.¬† One quickly realizes that while the eBusiness suite is comprised of hundreds of connected “Applications” (AR, AP, GL, CRM, and FA so on and so forth) it really is its own “system” that Oracle has built and bolted on to over the years.¬† By thinking of it in terms of systems, we can start to see how we can apply DevOps values into the system to solve issues that plague the system by and large – Complexity, Mean times to do anything,¬† long project cycles, operational silos, skill silos, deep reliance on vendor support and so much more.

I hope to see people join me on this journey, share their ideas & experiences and challenge my assumptions.¬† The end goal is absolutely a “cookbook” of ideas to bridge the Oracle Financials “monstrosity” (for lack of better word) into a DevOps value stream.

In opening the proverbial flood gates, I want to speak to you – the people implementing, supporting, planning, patching eBusiness suite and see what you are doing. I want to hear from Vendors working on solutions, from groups developing custom solutions to open source projects that can be used to help provide the tools for change and help consolidate some of this data to report back and share.

So please, contact me through my Blog,¬† LinkedIn, Twitter, Google Plus, e-mail or phone.¬† Let’s talk! BTW, This work will be shared here and on the DevOps Enterprise Patterns group I’ve volunteered to assist Gene Kim with as well. Please join us there!


DevOps Enterprise Patterns

Devops Audit Defense Toolkit

Contact Me!

Tagged , , , , , ,

Phoenix Project, the alternate Brent universe

I’ve read, and re-read the Phoenix Project and absolutely love it, learning something new each time and picking up new ideas to keep my brainstorming going, but one thought that has plagued me through to the end every time, is the “guardian angel” to management and the IT person staying the IT person.

How different would the story be if Brent was the benefactor of Erik’s advice?

In my years of experience, I often find the Brents of the industry aren’t wholly self-made but often easily fall into traps that we’re not taught to get out of.¬† It’s easy for management to rely on us, keeping us as the choke point of many critical projects without realizing it or facing it and we burn out, get angry, go BOFH.¬† We’re often managed into systems, managed into context and managed into a story and we often try and logic reason ourselves out of this with no end in sight. What if there was a different story?

How different would the Phoenix Project be if Brent was able to learn some leadership, learn some collaboration and develop his persuasion skills to help motivate and transform the organization and himself from within?¬† Would this story better help others facing similar situations? Would it help develop more leadership roles from the Brent types over the world? Would it help many of us Brent types “see the Forrest from the trees” more clearly?

The book is very good, don’t get me wrong, but I just have a gut feeling every time I read it that I wish Brent could have been developed, fostered and nurtured, not as a follower of management making changes but as the catalyst for management making changes and as a growth path for Brent himself, because I feel that better parallels my experience.¬† Obviously in the story Brent does benefit from the changes and we can all learn from the story, but in the end, it feels like a management win and it left me wondering how I could do something as if I’d just meet Erik.

I parallel this thought to many of the discussions I see on twitter and my own sorted experiences to help make changes at an organization.¬† In some tweets, I see people struggling to do what I’d call applied DevOps, replying to others to quit a job because they can’t convince management/peers of the logic of DevOps, people describing you must to this, do that, and run this or be that, and lots of frustration or indifference towards DevOps values by everyone else but them.¬† I’ve just been insanely curious about trying to parallel the story of the Phoenix Project to myself, my own short comings, my own experiences and those I observe (such as the mentioned tweets and indifference) and how to approach this. It was an awaking of sorts after reading MANY stories and books on leadership and growth that not only are a lot of “Brents” trying to make these changes in their organizations¬† but ironically they do so in a very “Brent” way¬† and here is how I’d answer that story.

For me, the new story steams from a few books I’ve read (mentioned below) and an excellent class available from the Teaching Company – Transformational Leadership and how I thought this could make a new Story for Brent if Brent meet Erik and hand the skills to transform.

How to sell DevOps at your org if Brent was the benefactor of Erik’s advice.
The hard way – The Brent way of convincing organizations of devops.

  • Strongly stated position – speak to things as facts – applied “DevOps” – get focused on mimicking successful organizations more than anything else. We’re good at having strong views and strongly stated positions.
  • Assertive Supporting Arguments – “This is the way, we must do this or else…” – Our logic is what we feel makes us assertive and how we speak objectively to something as if that will win people over.
  • Closing the deal – resisting compromise, using only logic/data and extreme passion to make out point.¬† Combining everything above, we often trap ourselves into an all or none type system/belief.

Would the book have made much more sense to many of us if Brent was developed to learn better collaboration? Be a better leader?¬† Would you be able to recognize the hard way above as the hard way? After all, most leaders are taught that the better way of persuasion (and leadership) is, collaborative persuasion. Collaborative persuasion helps us achieve the very goals we convey and yet, we don’t speak or really practice to this much, if any at all. While I felt the leadership story in Phoenix Project was very mature and bold, I’d just like to see more parallels of how Brent could have been fostered to lead the transition too and I believe many of us do it the hard way, or Brent way.

The Collaborative Way – Collaborative persuasion – using the very concept we’re trying to convey as a solution as the solution.

  • Establish Credibility – Don’t over estimate your own self!¬† (Big thing for us Brent types!)¬†– Conduct experiments & develop pilots to share what we’re trying to sell. Build credibility as DevOps applies to YOUR organization. Begin Somewhere!
    Build TRUST! Would Brent be able to experiment¬† (Vs jump to applying) with the advice of Erik? Could we translate that to Management/Leadership? Could we do so without falling back to our logical bias and do it collaborative for small wins and tactical leadership positions? Automation may be Brent’s goal idealistically (it is after all, following our logical trend) but could we step back and be happy showing a Kanban process and the wins thereof or simply starting with communication? Could we lead the small wins to a strong catalyst for cultural changes? Sometimes culture defies logic and that’s tough for us Brent types to understand or often don’t comprehend at all.
  • Framing for common ground – It’s important to collaborate, it’s important to explain things and frame them in such a way to express ourselves better.¬† Instead of saying “this must be the way, look, everyone else is succeeding at it” frame the topic so that the focus is drawn to the attention of where you desire to be. Lead people to positive results.¬† Framing is how you can steer the DevOps story to be better applicable and connected to your organization.
  • Connect emotionally – Is this possible for Brents of the world? Can we adopt our strategy to a broad audience in a collaborative way that connects with management and works through these gatekeepers? Can you focus on the divergent thinking to make it happen? Are we presenting REAL solutions or are we presenting problems? I know it’s terribly easy for us Brents to focus on problems and solutions as if their logically black and white. Can you connect emotionally to your peers and speak to them as if you put on their shoes?
  • Evidence – how can we build stories, examples and metaphors?¬† How can we make this evidence connect emotionally? Frame it for common ground? Build trust and establish credibility?¬† Evidence absolutely comes natural for many of us “logical Brents” but the hard part is connecting it to the collaborative persuasion process and realizing that this collaborative persuasion it was grows us from a Brent who may have learned something and wants to achieve it into a Brent who becomes a leader to enact it.

Brent types can transform to be leaders. As leaders, we don’t need formality to express our desires, we need strategy, history, allies, solutions and we need to work with and through the gatekeepers to tell the DevOps story. I think once we learn this, we also learn that perhaps there isn’t an absolute way for everything, that collaboration can lead to new ideas, new thoughts and new models of getting things done. We can not only grow to become leaders, but grow in our understanding and interpretations of the values of DevOps and how those values benefit the growth of your organizations and just as much, if not more importantly the growth of ourselves.

So while the Phoenix Project didn’t focus on the Brent solution as many of us are or have been over the years, I hope this post invigorates you, Brent or not, to think differently, think like a leader and realize that what you are trying to achieve doesn’t have to be an effort of management directly, but an effort that when done right can come directly from you. I implore you twitters not to tell people to quit their job, give up, find something else to do or beg and chew your way up or simply try and mimic or apply logic as if that’s the only way –¬† as DevOps values aren’t something we believe in and force upon others, they’re¬† stories that connect emotionally and speak elegantly to us to learn, practice, share and collaborate on. We need to do better selling that story to management & leaders or better develop ourselves to become those management & leaders.

Thanks for your time.  I realize not every Brent wants to be a leader and may be quite content with an organization that delivers DevOps values for him/her, but at the same time, I think there are a lot of us who do want more and I hope this helps you think of how to achieve more and how to lead that effort in a very DevOps way.

Books & Resources I’ve drawn much of this from and wouldn’t want to do without ūüôā

PS, I’m terribly new to writing, feel free to leave any feedback about my style, grammar, spelling or any methods to improve.¬† I’m mostly sharing my stories and thoughts but I’m always open to improve.¬† Thanks!

As always, feedback appreciated.  Feel free to find me on twitter as well.

Tagged , , , , ,

Devops – It’s about critical thinking & the evolutionary “WHY” of Silos.

I believe one of the best things to ever come out of DevOps movement that no one seems to be describing is essentially an explosion of critical thinking and reasoning skills, The maturing of IT if you will. Some people prescribe different views or distill it into different methods such as C.A.M.S (Culture, Automation, Measure, Share), some people say it’s the destruction of silos, some say it’s just a cool cultural shift and an awakening of sorts. I’d like to take you on a short journey and focus on two things for this topic – the concept of critical thinking and silos.

I found this blog post by Ben Kepes VERY interesting, where he discusses the odd effect of DevOps teams becoming silo teams in and of themselves and how that could appear to be negative or wrong. While I think it is an interesting point to bring up, I think its made without looking at the “WHY” it happens and more of a conceptual view of “WHY” it shouldn’t happen. So lets put on our critical thinking caps and “think here for a minute” about the whys of silos ūüôā

From my perspective, the biggest reasons we see silos aren’t vanishing (and quite possibly are being replaced by new silos) is that the silos are the result of real differences of domain. By this I mean, the domain knowledge of your operations, development, analysts, QA, DBA’s, sysadmins, engineers or any group are essentially domains of expertise. When it comes to cultural changes, the best change we can do isn’t to squish these silos down and pretend they don’t exist, but to align them better and give them strategic significance. If a silo really is a moving target, lets align them so they’re all moving in the same direction!

It seems to me, we’re more focused on prescribing ideas rather than deriving solutions. We see improvements because we aligned developers and ops into a team and we think “wow, getting rid of those silos worked” but maybe the silos weren’t the problem to begin with, maybe it was a failure of alignment, workflow, poor cooperation and poor business decisions. By aligning people and connecting them to not only costs of doing business but the revenue of doing business the entire “WIP” chain can see the impact of their work as a whole, as a unit, and as a team (Something to Measure!). Much like the comparisons of WIP from an IT shop to WIP of a manufacturing floor as described in Gene Kim’s excellent book “The Phoenix Project” we have to remind ourselves that even though the mfr floor looks like its running on its own and well oiled and doing small and simple tasks – those small and simple tasks are not just the experience of repetition, but silos of domain knowledge and experience that you don’t NEED to squish and quite frankly, do better when left to be developed and fostered.

I had my first real world experience of this in the early 2000s when I worked at a manufacturing plant. I was a technical lead for implementing an upgraded ERP/MRP system and one day, the manufacturing union went on strike and we full-time employees were led out into the floor to run the plant to finish delivery of critical items. I never thought much about it other than how interesting of an experience it was to go through a labor strike and realize how specialized some of the manufacturing jobs are and how they can appear simple but be rather complex in the end.. I realized I couldn’t assemble tubes like they did, my ceramic painting skills were terrible and the output/workflow of my experience was disastrous at best. Again, after reading “The Phoenix Project” I had a few epiphanies and differing views of the “flattening of silos” that I just couldn’t figure out how to express for a while and it’s just barely coming out here. It dawned on me that the people working this assembly line have a domain knowledge of their own. The people fixing the assembly line have a domain knowledge of their own. When the line breaks, no one expects the line workers to come in during their off hours and fix it because they need to be bothered to learn something about what broke, The line maintenance and facilities crews do their thing. Both domain experts of workers and repairers also have their pipeline, their WIP, their process improvement and they coordinate and match these skills, not distill them and flatten them. So why have such an expectation in IT?

So long story short, I believe we need to do better at understanding the “silos” we complain about. Again, the existence of silos in and of themselves doesn’t mean that they’re all silos of control, silos of despair & silos of differences and if they are these described silos, well, there lies your problem. You can fix the flows, you can align the groups and you can integrate teams and get them working together without artificially ignoring domain knowledge the same way you can prevent domain knowledge creating artificial silos.

The “Why” of Silos isn’t necessarily a bad thing by itself. Have you ever put your critical thinking cap on and thought about YOUR personal “silos”? Are you able to be “culturally adept” but still hold on to personal prejudices against all things commercial or all things not invented here? Do you let your hatred of specific vendors / ideas / practices tunnel vision your beliefs? Are you using silos as a big stick to ignore domain knowledge and experience? Are we really being critical thinkers?

Think critically about your organization. Understand how important your role in IT is to the business and its bottom line. You’re all on the same team, and there may be many silos, but as long as all the silos are on the same “farm”, they really shouldn’t be a problem. In fact, you may soon realize that when your silos are there exactly when and where you need them and this may be more strategic and important than tearing them down and having everything scattered across the field.. metaphorically speaking ūüôā

We evolve into silos of domain expertise as a natural progression of our careers, aspirations and experiences. These silos can be very powerful if used wisely and correctly recognized and aligned by your organization. Perhaps DevOps is its own silo, especially if you imply DevOps with specific ideas, tools, solutions and services and that’s why I think silos are less important than we realize and the real concept we should be focusing on is “critical thinking” because it’s that skill that really matters. It’s critical thinking that will give you the gut feeling of what works and what doesn’t and where you need to align yourself and your peers within your organization.

Hope to write down more thoughts on this later.. what do you think?

Tagged , , , , ,
%d bloggers like this: