This months host is Mz Kitchen of Madame Chow's Kitchen. (The pictures through out this post are from Lori of Lori's Lipsmacking Goodness and Temperance of High on the Hog.) She is helping us launch our new website and celebrate our 1 yr Aniversary with this great recipe!

According to wikipedia, Beef Wellington "is a preparation of beef tenderloin coated with pâté (often pâté de foie gras) and duxelles, which is then wrapped in puff pastry and baked."

After doing quite a bit of research and experimentation, I put this recipe together. It's based on the Ultimate Beef Wellington by Tyler Florence, but I added a couple things and eliminated a couple others.

What is required: using the puff pastry (I've heard that there are vegan versions on the market, but I haven't found them), a protein, and the duxelles. You don't have to use beef, you can use chicken, or fish. If you're a vegetarian (I was a strict one for over 20 years), I recommend that you use tempeh or seitan as your protein. Why? Because moisture is the enemy here! Even pressed tofu will be too moist, and you will end up with extremely soggy pastry. Ultimately, though, it's up to you what protein you choose for the dish.

Cook the duxelles on low heat so that you have a chance to evaporate the liquid, but so that you don't burn the mushrooms and shallots. If you like your meat rare or medium rare, I suggest keeping the seared beef in the refrigerator until just before you put everything together - it took so long to brown my puff pastry, that the beef was well done. Fortunately, my husband said it was still moist, but using cold beef means that it will take longer to cook, giving your puff pastry the time to brown.

Here is a helpful Gordon Ramsey video. Please note that the recipe below does NOT include the ham that Ramsey is using in the video, but if you like the idea, go for it and use it! You can also make individual servings, but remember that you will have to adjust the cooking time accordingly - try 20 to 25 minutes to start, but be sure to check because cooking time will vary because of the thickness of the meat, the type of meat you are using, your brand of puff pastry, and your oven.

Beef Wellington

For the Duxelles:

3 pints (1 1/2 pounds) white button mushrooms
2 shallots, peeled and roughly chopped
4 cloves garlic, peeled and roughly chopped
2 sprigs fresh thyme, leaves only
2 tablespoons unsalted butter
2 tablespoons extra-virgin olive oil
Kosher salt and freshly ground black pepper

For the Beef:

1 (3-pound) center cut beef tenderloin (filet mignon), trimmed
Extra-virgin olive oil
Kosher salt and freshly ground black pepper
6 sprigs of fresh thyme, leaves only
2 tablespoons Dijon mustard
Flour, for rolling out puff pastry
1 pound puff pastry, thawed if using frozen (follow directions on the package)
2 large eggs, lightly beaten
8 ounces mousse pate, available in specialty cheese and appetizer cases of larger markets (optional)

Directions
To make the Duxelles:

Add mushrooms, shallots, garlic, and thyme to a food processor and pulse until finely chopped. Add butter and olive oil to a large saute pan and set over medium heat. Add the shallot and mushroom mixture and saute for 8 to 10 minutes until most of the liquid has evaporated. Season with salt and pepper and set aside to cool completely.

To prepare the beef:

Tie the tenderloin in 4 places so it holds its cylindrical shape while cooking. Drizzle with olive oil, then season with salt and pepper and sear all over, including the ends, in a hot, heavy-based skillet lightly coated with olive oil - about 2 to 3 minutes.

Using a rubber spatula cover evenly with a thin layer of duxelles. Season the surface of the duxelles with salt and pepper and sprinkle with fresh thyme leaves. When the beef is seared, remove from heat, cut off twine and smear lightly all over with Dijon mustard. Allow to cool completely.

I made the duxelles and seared the tenderloin about 10 hours in advance, and refrigerated both of them. It is important that these items are cold because you will be working with puff pastry, and if they're warm, they may cause the dough to melt before you get it in the oven.

About an hour before you plan to serve the Beef Wellington,preheat oven to 425 degrees F.

On a lightly floured surface, roll the puff pastry out to about a 1/4-inch thickness. Depending on the size of your sheets you may have to overlap 2 sheets and press them together.

Spread the duxelles mixture down in a column down the middle of the rolled out puff pastry. Thinly slice the mousse and cover the duxelles with it - every square millimeter doesn't have to be covered, but you're trying to make sure that every serving gets beef, duxelle, and mousse.

Remove beef from refrigerator. Set the beef in the center of the pastry and brush all the edges of the pastry with egg wash. Fold the longer sides over the beef, and seal. Trim ends if necessary then brush with egg wash and fold over to completely seal the beef - saving ends to use as a decoration on top if desired. Place the beef seam side down on a baking sheet.

Brush the top of the pastry with egg wash then make a couple of slits in the top of the pastry using the tip of a paring knife - this creates vents that will allow the steam to escape when cooking. Bake for 40 to 45 minutes until pastry is golden brown and beef registers 125 degrees F (rare) on an instant-read thermometer. Remove from oven and rest before cutting into 3/4-inch thick slices

From the Forums:

It was like the most succulent bite of beef with all the layers of flavor. I am not a big beef fan either. So for me to say this- it means a lot. Lori of Lori's Lipsmacking Goodness

I made this for my husband using a truffle mousse from Whole Foods, and he LOVED it. At first he wasn't sure, but then changed his opinion as he made his way through the dish. Mz Kitchen of Madame Chow's Kitchen

I recently agreed to join Facebook's fbFund incubator as a mentor. Part of that includes giving a presentation for the fbFund companies on the lean startup methodology. I just got word that this is going to be happening this coming Thursday, June 25 in Palo Alto (in the former Facebook HQ). Best of all, I got word they are specially opening this event up to you, dear readers. Priority will be given to employees of companies participating in the fbFund REV program, but I am confident that there will be room for members of the general public who want to attend. If you'd like to reserve a spot, please RSVP.

fbFund REV featuring Eric Ries

The Lean Startup

Host:	fbFund
Type:	Education - Lecture
Network:	Global

Date:	Thursday, June 25, 2009
Time:	1:30pm - 3:30pm
Location:	fbFund REV Garage
Street:	164 Hamilton
City/Town:	Palo Alto, CA
RSVP Here

So, if you are in the Bay Area and want to swing by Palo Alto on Thursday afternoon, come join the conversation. As always, if you're a reader, please do say hello.

In a lean startup, instead of being organized around traditional functional departments, we use a cross-functional problem team and solution team. Each has its own iterative process: customer development and agile development respectively. And the two teams are joined together into a company-wide feedback loop that allows the whole company to be built to learn. This combination allows startups to increase their odds of success by having more major iterations before they run out of resources. It increases the runway without additional cash.

Increasing iterations is a good thing - unless we're going in a circle. The hardest part of entrepreneurship is to develop the judgment to know when it's time to change direction and when it's time to stay the course. That's why so many lean startup practices are focused on learning to tell the difference between progress and wasted effort. One such practice is to pivot from one vision to the next.

Changing the vision is a hard thing to do, and should not be undertaken lightly. Some startups avoid getting customer feedback for precisely this reason: they are afraid that if early reactions are negative, they'll be "forced" to abandon their vision. That's not the goal of a lean startup. We collect feedback for one reason only: to find out whether our vision is compatible with reality or is a delusion. As Steve writes in the Four Steps to the Epiphany, we always seek to find a market for the product as currently specified, not conduct a focus group to tell us what the spec should be. If and only if we can't find any market for our current vision is it appropriate to change it.

So how do you know it's time to change direction? And how do you pick a new direction? These are challenging questions, among the hardest that an early startup team will have to grapple with. Some startups fail because the founders can't have this conversation - they either blow up when they try, or they fail to change because they are afraid of conflict. Both are lethal outcomes.

I want to introduce the concept of the pivot, the idea that successful startups change directions but stay grounded in what they've learned. They keep one foot in the past and place one foot in a new possible future. Over time, this pivoting may lead them far afield from their original vision, but if you look carefully, you'll be able to detect common threads that link each iteration. By contrast, many unsuccessful startups simply jump outright from one vision to something completely different. These jumps are extremely risky, because they don't leverage the validated learning about customers that came before.

I've spoken in some detail about a specific pivot that we went through at IMVU, when we decided to abandon the instant messaging add-on concept, and switch to a standalone instant messaging network. We went through another pivot when we switched again from instant messaging to social networking. Although I wish I could take credit for these pivots, the reality is that they were not caused by my singular insight or that of my other co-founders. Instead, they were made possible by a process-oriented approach that stimulated our thinking and encouraged us to take prudent risks. More than anything, it forced us to take advantage of necessity, the mother of invention. Here's what it looked like.

IMVU had a roughly two-month-long development cycle. Each cycle was punctuated by a meeting of our Business Advisory Board (BAB). At this meeting, we would present our goals for the cycle, all the raw results we'd managed to collect, and our conclusions about what was next. This created a forum for deep thinking and conflict over the direction of the company - a classic problem team activity. It gave the whole company license to go heads-down building product as fast as possible during the development cycle, acting as a solution team should. We knew we'd have the opportunity to think strategically at least once per cycle, so we could stay focused tactically in the meantime.

When it was time to pivot, there were usually certain signs that we'd look to. The most important one actually came from solution team activities. When your fundamental product hypothesis is wrong, the solution team is going to be chronically frustrated. You can try every kind of experiment, add new features, innovate like crazy, optimize the funnel - and get only modest results. One or two cycles of that kind of frustration and you might be able to blame the solution team for insufficient creativity. But eventually, as the company fails to find traction, you start to ask problem team questions: are we really solving an important problem for customers? Are our early adopters really adopting? And does our product really solve the problem we've promised them?

Ironically, although it's the solution team that is the early-warning system ("canary in the coal mine") for pivots, it's actually hard for the solution team to make the decision to pivot. That's why it's so essential to have a co-equal problem team. The more work you've sunk into a product or vision, the harder it is to let it go. As the CTO/VP Engineering, I was the worst offender. It was incredibly hard for me to throw out working code, especially when it was well-factored, unit tested, and generally brilliant (if I did say so myself). I was stuck between a rock and a hard place. Leading up to a pivot, each cycle, despite our best efforts, the metrics weren't good enough. We didn't believe the problem was that we weren't trying hard enough. But we also didn't want to believe that the work we'd expended so far was a waste. It was painful.

The problem team/solution team combined with the concept of the pivot provides a way out. First of all, remember that each team is cross-functional. That means that I (and other engineers) were able to participate in the problem team discussions. Just wearing a different hat made it easier to consider abandoning our work. Such discussions would have been impossible in our execution-oriented engineering team meetings. Context matters. Providing a full view of all the raw data helped, too. It allowed our advisors to help us see patterns we had missed, zooming out the viewpoint from the trees back to the forest. From that angle, it was easier to accept that our micro problems had macro causes.

The pivot helped even more. The hard part about abandoning work is the feeling of wasted effort, that we'd have been just as well-off if we had spent the past few months on vacation instead of working incredibly hard. By pivoting, we honor all the effort by recognizing that learning would have been impossible without the work of the solution team. And rather than just abandoning all that work, we look for ways to take advantage of it in our new direction.

That's the pattern we see in so many successful startups. They did everything they could to take advantage of what they'd built so far. Most engineers naturally think about repurposing the technology platform, and this is a common pattern. But there are a lot of other possibilities. I'd like to call out three in particular: pivot on customer segment, pivot on customer problem, or pivot on a specific feature.

In a segment pivot, we try to take our existing product and use it to solve a similar problem for a different set of customers. This happens commonly when consumer products get unexpectedly adopted in enterprise, as happened to my friends at PBworks. In those cases, the product may stay mostly the same, but the positioning, marketing, and - most importantly - prioritization of features changes dramatically.

In a customer problem pivot, we try to solve a different problem for the same customer segment. This is an exciting kind of change, usually. When doing intense customer development, the problem team can attain a high level of empathy with potential customers. If the results of that exercise is a realization that customers have a problem that our solution doesn't address, and that problem is more promising - it's time to pivot. Starbucks famously did this pivot when they went from selling coffee beans and espresso makers to brewing drinks in-house. They were still serving high-end coffee afficionados, but in a more convenient form. This paved the way for their crossing-the-chasm type breakthrough with mainstream customers.

In a feature pivot, we select out a specific feature from our current product and reorient the whole company around that. A good example is Paypal realizing that their customers were gravitating to the email-payments part of their original solution, and ignoring the complex PDA-based cryptography solution. In order to do this kind of pivot, you need to pay close attention to what customers are really doing, not what you think they should do. It also requires abandoning the extra features that make it hard for new customers to discover what's really valuable about the new, simplified solution.

Without the tools to pivot well, startups get stuck between two extremes: the living dead, still expending energy but not really making progress, always hoping the next new feature will cause traction to magically materialize, and the compulsive jumper, never picking a single direction long enough to find out if there's anything there. Instead of these dead-ends, use the problem and solution team framework and then: pivot, don't jump.

Hello, from Long Lane Honey Bee Farm. We are David & Sheri Burns operating a honey bee farm in Central Illinois. We not only enjoy beekeeping, but it is a passion for us too. We especially enjoy helping more and more people enter the wonderful hobby of beekeeping.

Beekeeping is more than just a few crazy people, wearing funny hats and risking their lives while playing with killer bees. First of all, beekeepers keep gentle bees. For the most part, honey bees are gentle, busy and are not aggressive. We raise queens, and we make sure that the queens we raise are from hives that are not aggressive. Of course the worker bees do have stingers, so proper handling of the bees along with adequate protective clothing is necessary. Beekeeping is a billion dollar industry. Millions of hives are kept by beekeepers across the US.

Because honey bees are becoming scarcer, it is important to educate our local communities on the important role honey bees play in providing us with healthy food through pollination of our crops. Without the honey bee our fruits and vegetables would be at great risk.

Here's a squadron of bees returning to base loaded heavily with nectar. Beyond needing our bees to provide our food, bees are just fun to keep! There is so much to learn and learning is fun. To keep bees and broaden our understanding of the honey bee is a wonderful and very therapeutic past time and hobby.

To help beekeepers enjoy beekeeping even more, we provide these beekeeping lessons, containing our own photos along with important information and advice in being a good beekeeper. If you enjoy these free online beekeeping lessons we encourage you to donate toward these lesson. There is a place at the end of lesson to donate, and we do appreciate it in advance. When considering a donation, think about how much it would cost if you had to purchase books or take a college course that contains all the information in these lessons.

Today, I want to share about keeping a strong queen in your hive.

Lesson 55: HOW TO TELL WHEN YOUR HIVE IS QUEENLESS

Queenlessness is serious. In fact, queenlessness is the single most greatest threat to a hive’s survivability than any other disease or pest. Yet, it is easier to correct and overcome than other pests and diseases. Then why is queenlessness such an issue? In this lesson I want to address several key factors about queenlessness: 1) Why do queens die or disappear? 2) How to determine if your colony is queenless 3) How to make a queenless colony queen right 3) What to look for when your hive is about to become queenless 4) How to determine how long your hive has been queenless 5) What causes a worker to start laying in a queenless hive 6) How to deal with a laying worker 7) Suggestions to help avoid your hive from becoming queenless.

Every hive has only one queen. Her primary role is to lay eggs, sometimes 1,000 – 3,000 a day. Without a prolific queen, the colony will never build up in population and will always lack adequate foragers, thus there will be a constant lack of incoming pollen, nectar and water. The colony will eventually become so weak that it will succumb to pests or diseases.

However, with a young and prolific queen a colony will quickly increase in population and ample supplies of pollen, nectar and water will allow the hive to expand, be productive and resist most common pests and diseases. Therefore, a queen right hive is essential at all times during the year. Queen right is a term used to define a hive that has a prolific queen. As you can see in the picture below of a hive, it is full of bees. We believe that by keeping a hive very crowded, but not congested, a hive remains strong enough to resist most pests and diseases.

Notice how the many bees cover almost all of the frames on top. I removed one frame to inspect and to be sure the queen is laying good. But even hives that are queen right can suddenly become queenless. How does this happen so quickly?

Why do queens die or disappear? Remember, honey bees are livestock. More specifically, bees are bugs, insects that are at great risk not only from the normal threat of nature, but also from the hostile world beyond the sweet clover fields and tranquil meadows. Traffic, pesticides, insecticides, and those who see all insects as a pest pose a great threat to the survival of the honey bee. Because a queen is a small ¾ inch bug, she too can perish for various reasons. She can become ill or old and die. She can accidentally be smashed by the beekeeper when frames are pushed back together or covers are placed on a hive. She can be killed by the other bees if she shows signs of inferiority. And when another queen is raised in the same hive, the queens will fight and only one will survive, but certainly they both can perish in the fight.

A virgin queen must fly out of the hive several times to mate. This mating flight can be very treacherous. She can easily become a tasty meal for a bird or fall victim to nasty weather while she’s out. And even if she does make it back, the question is, did she mate adequately. So even though a hive can successfully raise their own queen, there is no better proof that the colony has a prolific queen until eggs are visible.

How do we determine that our colony is queenless? No eggs. You can click on the images to see a larger version. Study the picture and familiarize yourself in identifying eggs and larvae. An egg stands up in the bottom of a cell. By day three, the egg has laid down on the bottom of a cell and hatched into a larvae. You can see the royal jelly surrounding the larvae in the picture.

Even if a mated queen is present but we see no eggs, we are essentially queenless. You’ll develop a skill that will allow you to open up your hive and listen to the bees and observe their behavior. A queenless hive usually has a louder roar, and usually appears more disorganized. If you do not see any eggs on any frames, then you are queenless.

How can we make a queenless colony queen right? Purchase a new, mated queen in a cage and introduce her to the new hive with a candy plug. Or if the hive is raising their own queen, allow them to do so. If you allow the colony to raise their own queen, you will have to wait longer until the virgin queen emerges, matures, mates and starts laying. If you purchase a mated queen, she will start laying within a few days.

Is there a way we can tell if our colony is about to become queenless? Yes and no. Obviously if the beekeeper smashes and kills the queen, this cannot be known in advance. However, if the current queen has space to lay but is laying poorly, then the colony may try to replace her soon or they may not. Or if you see mostly drone brood, which sticks up above the smooth worker brood more like bullets, then you know your queen will soon perish. Also, if you see queen cells, either swarm cells on the lower part of the frame or supersedure cells on the upper half of the frame, then watch your hive carefully. Something may be wrong and it may become queenless. Finally, if you know the age of your queen, then you can determine how long she has left. This is somewhat unknown because some queens can do real well for several years, maybe three or four years. Some are only good for one year. Therefore, it is best to requeen your colony each year.

When you find that your hive is queenless, it is important to know how long it has been without a queen. This will tell you how long you have to obtain a new queen. For example, if you see only sealed brood as in the picture to the left, you know that your queen has been gone for more than a week. Sealed brood looks different than sealed honey. Sealed brood is usually darker and more textured looking. Whereas sealed honey is brighter and looks more wet. If you need help learning the difference, just use a tooth pick and poke a cell to see what's inside. If you see unsealed larvae, then you have some time before your hive experiences the affects of queenlessness. But you should work promptly to provide a new queen.

The unsealed brood means that those bees will be hatching in about 15 days so you still have new bees on their way. Let me test you. If your queen is missing but you see what's in the photo to the left, how long has your queen been gone? You can click on the image to enlarge. Some of the larvae is sealed or capped, but some are exposed. So we know the capped larvae are atleast 8 days old and the uncapped ones are large enough to be atleast 6-7 days old. So you've been without a queen for about a week. You have time to act, but you must act fast to purchase a new mated queen so there will be a minimal gap of emerging workers to keep the hive strong.


However, if there are no eggs and no sealed brood, it means that you will have nothing more than what you have. Each day, your hive will become smaller in number because without emerging brood the older bees will die. If you have no brood at all, sealed or unsealed, then you have an emergency! You must get a queen within the next few days. Pay extra and have her sent overnight. Every day counts. Your hive is a mere 30 days away from total collapse. Act fast.

Once the queen has perished, and the hive has attempted but failed to raise a replacement, you must act fast because without a queen, workers could become what is known as a laying worker. With the strong pheromone of open brood, not the queen pheromone, the other female workers’ ability to lay is suppressed. But without open brood pheromones, several female workers may start laying eggs. But since a female worker is not fully develop as a layer nor has she ever mated, nor could she, then her eggs are all infertile thus they will only become drones, male bees.

A laying worker in a hive usually means certain death of the colony. Since a laying worker will only produce male drones, the absence of workers means certain collapse of your hive. A laying worker does not have the long abdomen of a queen so when she lays, she cannot always place her eggs on the bottom of a deep cell. The eggs are often found on the side of a cell. But the obvious sign that you have a laying worker is that each cell contains many eggs. Sometimes a newly mated queen or a queen without room to lay may lay more than one egg in a cell, but a laying worker will fill up a cell with eggs. Study my photo here to familiarize yourself with what the eggs look like from having a laying worker. See the numerous eggs in the cells. Remember to click on the image to enlarge for a closer look.

It is suggested that even strong, queen right colonies always have a few laying workers, but the bees keep them in check. From the photo, can you see which one is the laying worker? No, you cannot. They are impossible to spot.

How do you get rid of a laying worker? Some say you can dump all the bees out in the yard, twenty feet or more away from the hive and the laying worker cannot find her way back in. Others say she can and will fly back. Some claim to have made special queen introduction cages which allow the newly mated queen to lay eggs on comb under a cage and eventually the bees will kill the laying worker. But introducing a queen into a hive with a laying worker often means the laying worker and her gang will attack and kill the newly introduced queen. And you’ll never find a laying worker. Don’t even bother trying, they all look the same.

I’ve had success by introducing new queens in cages into a laying worker hive, but it does take several tries. Unless you raise your own queens, this can be costly. It is easiest for me to remove a few frames from a queen right hive with the queen on it, and place them against the wall of a laying worker hive. The good queen along with her two frames of bees seem to seek and destroy the laying worker. Then you can easily replace the queen that you removed from the queen right hive.

The traditional solution is to take all the frames out of a laying worker hive and give them to strong colonies. The strong colony will usually kill the laying worker.

Finally, how can beekeepers protect their hives from becoming queenless?

Inspect your hive every 2 weeks. You do not necessarily have to spot the queen as long as you see that there is a good number of eggs and larvae. The photo to the left is what you want to find. Brood in various stages including eggs. This photo shows eggs near the edge of the frame.

Also be sure there is plenty of room for the queen to lay. If you see your hive is honey or pollen bound, you either have to shake out the pollen or extract the honey or put in empty drawn comb if you have some available. Failure to provide room in your hive for expansion can cause the bees to become congested. Remember we advocated crowded hives, but not congested hives. A congested hive means there is no more open, drawn out cells for the queen to lay in, or the forages to store pollen and nectar. Thus they will prepare to swarm.

Yesterday one of our hives did just that. Because we crowd our hives, they can become congested faster than we can sometimes give them drawn comb. But we'd rather err on the side of being too crowded than having a small and weak colony. Swarms are friendly. This swarm was gracious enough to agree to have their picture taken with me. I later shock them into a new hive and they are content now. By the way, if you are a beekeeper, you absolutely must have an extra hive on hand to catch swarms, swarms that come from your hive or for when you are called upon to help save a swarm near you. Yesterday a gentleman called us because he caught a swarm and had nothing to put it in.

Fortunately, we rushed him out a hive. But we cannot always send a hive right out, so please plan ahead. June is a big swarm month. Hives seem to swarm more on the first nice day after a storm or rainy weather. Now the hive that produced this swarm may become queenless. Hopefully they did their job, and produced a new queen. The old queen leaves with the swarm and the new emerging queen takes over. But remember, she is virgin queen, and must fly a mile or two away to mate with other drones, not from her hive. She can be killed in her flight by birds or storms. Will she make it back, and will she be mated well. Much is at stake.


Replace your queen yearly to ensure you have a young, prolific queen. Each day we send out queens to beekeepers across the country. These are queens that we raise from our honey bee farm that show the characteristics that we want in a honey bee.

We gather queens from their mating nucs once they've proven to be good layers. Then we add 4 attendants to care for the queen during shipment. Then, we add the candy plug along with one drop of water for the 1-2 day trip. It works out well.



We have mating nucs scatter throughout. The queens do not mate in the nuc, but it merely provides a place for the queen to live, be cared for and to show how well she can lay after she mates.


These mating nucs are near a cedar tree and use it as a land mark to find their way back to their specific hive. It is amazing that a queen can fly out, travel for miles to mate, and return home.

I was holding a virgin queen in my hand a few weekends ago, showing her to several people. She took flight, flew around a few times and was gone. The people were sad that she flew away. About twenty minutes later, she came back and landed on my leg. I picked her up and put her back in her cage. She did not mate on this flight. When queens return home from mating, they have the last male's genitalia still attached. Even though she returned home without a mating sign, it was still impressive that she had such a great sense of orientation and returned to her original take off point.

In fact, in my main mating yard, I can't even find my way around, but the queens do great picking out which hive is their home.


Some people use colors or markings on the hives or physical land marks, but we've found that for the most part the queens do fine finding their way back home.

Well, this concludes today's lesson and I hope it has been helpful to you in being able to keep your hive queenright!

Did you know that thousands of people read these lessons? And nearly 1,000 people have subscribed to receive these lessons directly to their email address. We want to thank each of you for your support of these free online beekeeping lessons and for sharing them with others.

If you want to subscribe and have these lessons sent to your email address, click here.

Enter your Email and we'll send you these lessons automatically





Preview Powered by FeedBlitz

You can easily unsubscribe at any time and it's free. Since these lessons are free, it doesn't take a rocket scientist to figure out that it does take money and time to put each lesson together. We receive alot of "thank you" emails and phone calls, telling us that these lessons have helped beekeepers greatly.

We welcome your donations toward producing more free lessons. Click the image here to make your donation. We appreciate it! If the link or image does not work well for you, then you can send your donation to: Long Lane Honey Bee Farms, C/O Free Lessons, 14556 N. 1020 E. Rd, Fairmount, IL 61841

If you need a queen or hive equipment, please feel free to give us a call. Since we have over 100 hives, we may not answer, so please leave a message. Our contact info is below.

Until next time, BEE-have yourself!

David & Sheri Burns
LONG LANE HONEY BEE FARMS
http://www.honeybeesonline.com/
217-427-2678

Of all the tactics I have advocated as part of the lean startup, none has provoked as many extreme reactions as continuous deployment, a process that allows companies to release software in minutes instead of days, weeks, or months. My previous startup, IMVU, has used this process to deploy new code as often as an average of fifty times a day. This has stirred up some controversy, with some claiming that this rapid release process contributes to low-quality software or prevents the company from innovating. If we accept the verdict of customers instead of pundits, I think these claims are easy to dismiss. Far more common, and far more difficult, is the range of questions from people who simply wonder if it's possible to apply continuous deployment to their business, industry, or team.

The particulars of IMVU’s history give rise to a lot of these concerns. As a consumer internet company with millions of customers, it may seem to have little relevancy for an enterprise software company with only a handful of potential customers, or a computer security company whose customers demand a rigorous audit before accepting a new release. I think these objections really miss the point of continuous deployment, because they focus on the specific implementations instead of general principles. So, while most of the writing on continuous deployment so far focuses on the how of it, I want to focus today on the why. (If you're looking for resources on getting started, see "Continuous deployment in 5 easy steps")

The goal of continuous deployment is to help development teams drive waste out of their process by simultaneously reducing the batch size and increasing the tempo of their work. This makes it possible for teams to get – and stay – in a condition of flow for sustained periods. This condition makes it much easier for teams to innovate, experiment, and achieve sustained productivity. And it nicely compliments other continuous improvement systems, such as Five Whys.

One large source of waste in development is “double-checking.” For example, imagine a team operating in a traditional waterfall development system, without continuous deployment, test-driven development, or continuous integration. When a developer wants to check-in code, this is a very scary moment. He or she has a choice: check-in now, or double-check to make sure everything still works and looks good. Both options have some attraction. If they check-in now, they can claim the rewards of being done sooner. On the other hand, if they cause a problem, their previous speed will be counted against them. Why didn't they spend just another five minutes making sure they didn't cause that problem? In practice, how developers respond to this dilemma is determined by their incentives, which are driven by the culture of their team. How severely is failure punished? Who will ultimately bear the cost of their mistakes? How important are schedules? Does the team value finishing early?

But the thing to notice in this situation is that there is really no right answer. People who agonize over the choice reap the worst of both worlds. As a result, developers will tend towards two extremes: those who believe in getting things done as fast as possible, and those who believe that work should be carefully checked. Any intermediate position is untenable over the long-term. When things go wrong, any nuanced explanation of the trade-offs involved is going to sound unsatisfying. After all, you could have acted a little sooner or a little more careful – if only you’d known what the problem was going to be in advance. Viewed through the lens of hindsight, most of those judgments look bad. On the other hand, an extreme position is much easier to defend. Both have built-in excuses: “sure there were a few bugs, but I consistently over-deliver on an intense schedule, and it’s well worth it” or “I know you wanted this done sooner, but you know I only ever deliver when it’s absolutely ready, and it’s well worth it.”

These two extreme positions lead to factional strife in development teams, which is extremely unpleasant. Managers start to make a note of who’s on which faction, and then assign projects accordingly. Got a crazy last-minute feature, get the Cowboys to take care of it – and then let the Quality Defenders clean it up in the next release. Both sides start to think of their point of view in moralistic terms: “those guys don’t see the economic value of fast action, they only care about their precious architecture diagrams” or “those guys are sloppy and have no professional pride.” Having been called upon to mediate these disagreements many times in my career, I can attest to just how wasteful they are.

However, they are completely logical outgrowths of a large-batch-size development process that forces developers to make trade-offs between time and quality, using the old “time-quality-money, pick two fallacy.” Because feedback is slow in coming, the damage caused by a mistake is felt long after the decisions that caused the mistake were made, making learning difficult. Because everyone gets ready to integrate with the release batch around the same time (there being no incentive to integrate early), conflicts are resolved under extreme time pressure. Features are chronically on the bubble, about to get deferred to the next release. But when they do get deferred, they tend to have their scope increased (“after all, we have a whole release cycle, and it’s almost done…”), which leads to yet another time crunch, and so on. And, of course, the code rarely performs in production the way it does in the testing or staging environment, which leads to a series of hot-fixes immediately following each release. These come at the expense of the next release batch, meaning that each release cycle starts off behind.

Many times when I interview a development team caught in the pincers of this situation, they want my help "fixing people." Thanks to a phenomenon called the Fundamental Attribution Error in psychology, humans tend to become convinced that other people’s behavior is due to their fundamental attributes, like their character, ethics, or morality – even while we excuse our own actions as being influenced by circumstances. So developers stuck in this world tend to think the other developers on their team are either, deep in their souls, plodding pedants or sloppy coders. Neither is true – they just have their incentives all messed up.

You can’t change the underlying incentives of this situation by getting better at any one activity. Better release planning, estimating, architecting, or integrating will only mitigate the symptoms. The only traditional technique for solving this problem is to add in massive queues in the forms of schedule padding, extra time for integration, code freezes and the like. In fact, most organizations don’t realize just how much of this padding is already going on in the estimates that individual developers learn to generate. But padding doesn’t help, because it serves to slow down the whole process. And as all development teams will tell you – time is always short. In fact, excess time pressure is exactly why they think they have these problems in the first place.

So we need to find solutions that operate at the systems level to break teams out of this pincer action. The agile software movement has made numerous contributions: continuous integration, which helps accelerate feedback about defects; story cards and kanban that reduce batch size; a daily stand-up that increases tempo. Continuous deployment is another such technique, one with a unique power to change development team dynamics for the better.

Why does it work?

First, continuous deployment separates out two different definitions of the terms “release.” One is used by engineers to refer to the process of getting code fully integrated into production. Another is used by marketing to refer to what customers see. In traditional batch-and-queue development, these two concepts are linked. All customers will see the new software as soon as it’s deployed. This requires that all of the testing of the release happen before it is deployed to production, in special staging or testing environments. And this leaves the release vulnerable to unanticipated problems during this window of time: after the code is written but before it's running in production. On top of that overhead, by conflating the marketing release with the technical release, the amount of coordination overhead required to ship something is also dramatically increased.

Under continuous deployment, as soon as code is written, it’s on its way to production. That means we are often deploying just 1% of a feature – long before customers would want to see it. In fact, most of the work involved with a new feature is not the user-visible parts of the feature itself. Instead, it’s the millions of tiny touch points that integrate the feature with all the other features that were built before. Think of the dozens of little API changes that are required when we want to pass new values through the system. These changes are generally supposed to be “side effect free” meaning they don’t affect the behavior of the system at the point of insertion – emphasis on supposed. In fact, many bugs are caused by unusual or unnoticed side effects of these deep changes. The same is true of small changes that only conflict with configuration parameters in the production environment. It’s much better to get this feedback as soon as possible, which continuous deployment offers.

Continuous deployment also acts as a speed regulator. Every time the deployment process encounters a problem, a human being needs to get involved to diagnose it. During this time, it’s intentionally impossible for anyone else to deploy. When teams are ready to deploy, but the process is locked, they become immediately available to help diagnose and fix the deployment problem (the alternative, that they continue to generate, but not deploy, new code just serves to increase batch sizes to everyone’s detriment). This speed regulation is a tricky adjustment for teams that are accustomed to measuring their progress via individual efficiency. In such a system, the primary goal of each engineer is to stay busy, using as close to 100% of his or her time for coding as possible. Unfortunately, this view ignores the overall throughput of the team. Even if you don’t adopt a radical definition of progress, like the “validated learning about customers” that I advocate, it’s still sub-optimal to keep everyone busy. When you’re in the midst of integration problems, any code that someone is writing is likely to have to be revised as a result of conflicts. Same with configuration mismatches or multiple teams stepping on each others’ toes. In such circumstances, it’s much better for overall productivity for people to stop coding and start talking. Once they figure out how to coordinate their actions so that the work they are doing doesn’t have to be reworked, it’s productive to start coding again.

Returning to our development team divided into Cowboy and Quality factions, let’s take a look at how continuous deployment can change the calculus of their situation. For one, continuous deployment fosters learning and professional development – on both sides of the divide. Instead of having to argue with each other about the right way to code, each individual has an opportunity to learn directly from the production environment. This is the meaning of the axiom to “let your defects be your teacher.”

If an engineer has a tendency to ship too soon, they will tend to find themselves grappling with the cluster immune system, continuous integration server, and five whys master more often. These encounters, far from being the high-stakes arguments inherent in traditional teams are actually low-risk, mostly private or small-group affairs. Because the feedback is rapid, Cowboys will start to learn what kinds of testing, preparation and checking really do let them work faster. They’ll be learning the key truth that there is such a thing as “too fast” – many quality problems actually slow you down.

But for engineers that have the tendency to wait too long before shipping, they too have lessons to learn. For one, the larger the batch size of their work, the harder it will be to get it integrated. At IMVU, we would occasionally hire someone from a more traditional organization who had a hard time letting go of their “best practices” and habits. Sometimes they’d advocate for doing their work on a separate branch, and only integrating at the end. Although I’d always do my best to convince them otherwise, if they were insistent I would encourage them to give it a try. Inevitably, a week or two later, I’d enjoy the spectacle of watching them engage in something I called “code bouncing.” It's like throwing a rubber ball against the wall. In a code bounce, someone tries to check in a huge batch. First they have integration conflicts, which require talking to various people on the team to know how to resolve them properly. Of course, while they are resolving, new changes are being checked in. So new conflicts appear. This cycle repeats for a while, until the team either catches up to all the conflicts or just asks the rest of the team for a general check-in freeze. Then the fun part begins. Getting a large batch through the continuous integration server, incremental deploy system, and real-time monitoring system almost never works on the first try. Thus the large batch gets reverted. While the problems are being fixed, more changes are being checked in. Unless we freeze the work of the whole team, this can go on for days. But if we do engage in a general check-in freeze, then we’re driving up the batch size of everyone else – which will lead to future episodes of code bouncing. In my experience, just one or two episodes are enough to cure anyone of their desire to work in large batches.

Because continuous deployment encourages learning, teams that practice it are able to get faster over time. That’s because each individual’s incentives are aligned with the goals of the whole team. Each person works to drive down waste in their own work, and this true efficiency gain more than offsets the incremental overhead of having to build and maintain the infrastructure required to do continuous deployment. In fact, if you practice Five Whys too, you can build all of this infrastructure in a completely incremental fashion. It’s really a lot of fun.

One last benefit: morale. At a recent talk, an audience member asked me about the impact of continuous deployment on morale. This manager was worried that moving their engineers to a more-rapid release cycle would stress them out, making them feel like they were always fire fighting and releasing, and never had time for “real work.” As luck would have it, one of IMVU’s engineers happened to be in the audience at the time. They provided a better answer than I ever could. They explained that by reducing the overhead of doing a release, each engineer gets to work to their own release schedule. That means, as soon as they are ready to deploy, they can. So even if it’s midnight, if your feature is ready to go, you can check-in, deploy, and start talking to customers about it right away. No extra approvals, meetings, or coordination required. Just you, your code, and your customers. It’s pretty satisfying.

I haven't had much time to write lately, and so haven't been able to share much about the Lean Startup Workshop series I have been producing with O'Reilly in their Master Class division. We had the first event last month, and the next is coming up on June 18th. The May workshop was a huge success, with much better turnout and feedback than I had any right to expect. I'm incredibly grateful to the early adopters who were able to be there. Thank you all.

Part of what made the workshop so successful was the caliber of the participants in the room. These were serious entrepreneurs who have the vision to see how the lean startup concept can help them increase their odds of success. Thus, the quality of the questions I was asked, the discussion in the room during exercises, and the overall intensity was higher than anything I've experienced in any other venue. That's why I'm so excited about this format. (For more on what it was like, you can read an in-depth review from the first workshop here).

So far, we have limited registration at the workshops to people who can afford the admittedly high cost of entry. I believe this is part of what made the first workshop such a success - the people in the room were visionary customers who therefore came ready to work, not just to be entertained (by contrast with what I see at some of my speaking engagements). However, this financial bar has had the effect of excluding one segment of potential customers that I'd really like to see there - early stage entrepreneurs who have all the intelligence and vision of their later stage counterparts, but simply cannot afford the cash flow to attend.

Thus, I'm excited to announce that we're trying an experiment in providing scholarships for worthy entrepreneurs. For starters, we've reserved a few seats in the June 18th workshop (next week), and O'Reilly has agreed to jointly sponsor these scholarships with me. We're also soliciting additional sponsors for future workshops; if you or your company are interested, please let me know. The next two workshops aren't scheduled until the fall (Oct 30 in SF, Dec 10 in NYC) - look for a separate announcement about those.

These scholarships will provide extremely discounted pricing for entrepreneurs who demonstrate that they would contribute positively to the discussion in the room. They are not for people who are casually interested - we're looking for more early adopters. If you think you meet that description, and want to come join us on June 18th, please send me an email with a brief less-than-one-page (please, no more) explanation of why you want to be there. We'll reply by email if you are selected to attend.

Once again, thanks to all of you for your passion and support. For more on the workshop series, you can read about them here.

Welcome to Long Lane Honey Bee Farms! We are David & Sheri Burns, and we enjoy making a livelihood from bees. Now that it is June, our bees are really keeping us busy. It has been another challenging spring. We've had our share of rain and cool weather, but as the season progresses the weather conditions improve. We are producing lots of nucs and queens. We were issued a clean bill of health from our state's apiary inspection program through the Department of Agriculture, so we are happy about that! Now, I'm spending long days preparing the nucs. We sold over 60 nucs, so that's keeping me out in the bee yards all day long.

Our queens are doing great again this year, and filling up the brood area faster than we can keep new frames supplied for the queens to have room to lay. We are working hard every day grafting and raising queens! We are having very good results both in successful queen rearing techniques as well as the characteristics that we are seeing in our queens. Our queens orders are about a week behind but we are producing queens as fast as we can. It does take time to properly test the queens characteristics and make sure they are mated well. Queen rearing is a fine art. We have even added a few "trade secrets" to make our queens even better this year. We had to take the queens off our website due to demand out running supplies.
This is the time of year for swarming and we are having our fair share of swarms this year. No matter how many swarms we have, it is still beautiful to observe. A swarm is worthy of our full attention. Until you've stood in the middle of a swarm before, you can't say you've really experienced a swarm. My son was weed-eating and heard a swarm roar over the sound of the weed-eater!

Below is a video of a swarm that I shook from a tree near my nuc yard. Healthy hives swarm! Seriously, a reproductive swarm means that the hive was strong and healthy enough to produce another colony. Another reason bees swarm is because they become congested. Another "trade secret" that I will share with you, is that we overcrowd our hives and in so doing, they often become congested. I feel it is better to have a strong, crowded colony than a weak and struggling hive. Strong and crowded hives are more apt to resist pests and diseases. There is strength in numbers. As a result of the way we overcrowd our hives, we do have the occasional swarm like this one. Let me show you how I shake swarms from trees.

For the most part, swarms are not aggressive. I am occasionally stung by bees from a swarm but usually not. If you keep your hives near bushy trees like pines or a blue spruce, they usually land in the tree low enough where you can capture them and put them in a hive.

I learned something from an "old timer" beekeeper who said if beekeepers would stop chasing swarms and spend that time taking care of their own hives, they'd have better hives. I tend to agree with him. We have turned down most of this year's swarm calls. It just isn't worth it.

I' ve found that swarms like to land in my old ceder tree. This tree has been the resting place for many swarms over the last few years.

Not all swarms land low. Here's my oldest son, David, after he climbed a 30 foot tree with a Bee-Vac and captured a swarm that filled this entire holding cage. It was on the trunk of the tree and would have been impossible to remove without a bee-vac. We sell these, by the way.

The only reason I occasionally catch a swarm is to use it to draw comb. Swarms are good comb builders! Sometimes that's the only thing I use swarms for is to draw out foundation.

It's usually the old queen that leaves with the swarm, so when you catch a swarm it is usually a good idea to re-queen that swarm or it may not make it through the upcoming winter with the older queen.

In April, I flew down to Florida to shake packages and as you may remember from an earlier lesson, I mentioned that I was able to visit with commercial queen producer, David Miksa. In the April and May issue of the American Bee Journal, David was featured in a large article about his life long pursuit of producing queens. Every year I continue to sharpen my queen rearing skills and it is through knowing people like Dr. Joe Latshaw and David Miksa and others that I am able to improve my line of queens. I added about 5 different "survival" genetic stocks that I purchased from other parts of the US. I believe genetic diversity is crucial to very productive queens.

When I visited David Miksa, I was impressed with his incubator. When you produce large numbers of queens, you will need a place to hold sealed queen cells, especially when there is a bottle neck, say your mating nucs are still full as you wait for those queens to mate and to be used in hives or sold. What I like about David's incubator is that it has a glass door. And as we talked about it, he told me that it was just a glass door refrigerator. He added a heating element along with dual thermostats in case one goes bad.

Last year we used a "Little Giant" 9200 chicken egg incubator. They are around $50 and you'll need to keep your cells at around 92 degrees.

When I was at Sam's Club a few weeks ago, I noticed that they had a nice size, small, pop-can refrigerator just alittle over $150 with a glass door. With a glass door, you can more easily see your cells and monitor the temperature and humidity. It fits nicely under my counter.

I bought it and then removed the important parts from my 9200 chicken incubator and placed the heating elements and thermostat on a piece of plywood. Then, I placed the electronics on the bottom shelf of the fridge.

I wired the heating element up by routing it through the drain hole in the lower back part of the inside fridge. So, I didn't have to make any alterations to the fridge. So when I'm not raising queens, I can use it for an extra fridge.

You'll find as a beekeeper you can save lots of money by making your own incubator instead of buying one. Many queen producers make it even more simple by taking an old fridge, even one that no longer works, and simply place a low wattage light inside. You can wire the door switch so that the light is always on, and then put it on a thermostat to keep it around 92 degrees using a VERY low watt bulb. That's right, a light bulb will keep it warm enough. This works well too. There are lots of old refrigerators out there, and you may even fine one with a glass door.

I hope that by sharing insightful information about queen rearing, that more and more beekeepers may try their hand at it. It is quite easy and very enjoyable and rewarding, not to mention it can save you money from not having to buy queens when you need them. And by raising your own queens, you can also raise queens from the hives that you like best.

Also in this lesson, I want to WARN you to keep an eye on your queen. Inspect your hive every 14 days to be sure she is alive and laying well. If you lose your queen, your entire hive will all perish within 6 weeks, so be sure to keep an eye on your queen, and replace her with a new one at the first sign that she has perished.

Here's a picture of one of our "Pioneer Queens" this year. Also, I must stress how important it is that you replace your queen every year. When a virgin queen mates, she stores the sperm from the drones in her spermatheca. She usually mates with 15-20+ drones on a few mating flights. Because she stores the sperm, she will eventually run out. Then, she can only lay unfertilized eggs, which only makes drones, male honey bees. So by requeening your hive every year, you are insuring that she is able to lay strongly throughout that year and into the next spring.

People often ask me when is the best time to requeen a hive. Typically, any time is better than not doing it at all. Bees requeen their own hives whenever there is a need, so we can too. But I believe timing of requeening each year can produce different results. In other words, if your old queen is starting to not lay well in March, then by all means replace her so that you can have the results you want in March which is a better brood pattern, which means more bees. But, if you are replacing your queen simply because you want a younger queen, then you MUST do this after the turning of days (June 21).

Melvin Disselkoen became an EAS Master Beekeeper in 1986 and has worked bees for over 35 years. He wrote an article about outbreeding the mites. His research and explanation of outbreeding the mites makes real good sense, and it was while reading his work that I realized it is best to requeen after June 21.

His complete article on this can be found on his website at:

http://www.mdasplitter.com/article.htm

His point is that if you requeen after July 21, a new queen will outbreed the mites. The brood cycle of a mite is 13 days, and a worker bees is 16 days. Since a new queen after June 21 lays like a spring queen, she will out-lay the mites. Less mites means healthier overwintered colonies and better spring build up. That's a huge reason to wait until after June 21. Other reasons for requeening each year include: swarm reduction, stronger spring build up, better honey production due to increased spring foragers and more.
I've also been very busy preparing nucs. Some days I spend 12 hours a day working the hives to pull out 4 frames to meet our nuc demands. I'll be glad when the last of the nucs are gone! Here's a picture of my youngest son, Christian, after we packed up some nucs. These were a special order as you can see they are nucs, but they are all on medium foundation. Some beekeepers like using all medium size boxes rather than the larger deep hive bodies. We are happy to help out. Beekeeping is usually a skill based on knowledge, wisdom and experience. However, I've learned that making nucs is an art! It is not for the faint at heart.

I could go on and on, but I do want to address a very large problem within the beekeeping community. It's not CCD, though there are more cases of it than CCD, I'm sure. The problem I'd like to address is the disappearing hive tool. Where do they go? How can they disappear? Are aliens from other planets stealing our hive tools with some huge magnet from the mother ship? I doubt it. But I've solved my personal problem of lost hive tools. I bought a nice one! :)

Not only do I lose hive tools, but I leave them in the back of pickup trucks or on top of a hive, and because they are metal, they will rust. Leave one on the ground all winter, and it will almost rust away by spring.  Click here to go to our online store for this item. 

If you are still needing hive equipment you can order it online or give us a call. Our contact information is below. Thanks so much for following these lessons!

Until next time, remember to Bee-have yourself!

David & Sheri Burns

Long Lane Honey Bee Farms

www.honeybeesonline.com

217-427-2678

EMAIL: david@honeybeesonline.com

Banyak di antara kita seringkali tidak menghargai masa. Banyak sekali masa yang dibiarkan begitu sahaja. Melakukan persediaan hanya apabila waktu telah hampir tamat.

Persediaan untuk final exam dilakukan ketika study week. Dalam seminggu itulah segala nota dibelek, segala rujukan dicari, segala fakta dihafal, segala tips diselidik. Dan peristiwa yang paling menyanyat hati adalah apabila ada yang sanggup tidak makan dan tidur kerana mahu meng'cover' semua yang dirasakan perlu untuk menjawab soalan peperiksaan yang bakal menjelang. Inilah yang dikatakan 'melakukan persediaan'.


Ini semua masih boleh dilakukan dengan syarat kita tahu bila 'dateline' untuk sesuatu perkara itu. Lalu kita masih boleh berlengah-lengah dengan alasan,

"Lama lagi, relax dululah..nanti dah nak dekat tarikh barulah sedia.."

Tapi adakah kita bersedia tatkala tiba-tiba diadakan pop quiz? Ramai kawan-kawan memberi alasan,

"Alah, quiz je, tak banyak pun carry marks dia, paling-paling pun 1%-2%. Yang penting test dan final exam."

Amboi..sedap demo royak..koya blanar!* Nasib baiklah pensyarah tak pernah buat pop test. Kalau ada, mesti ramai kantoi.

*(sila tanya kawan-kawan dari kelantan apakah maksudnya)

Tetapi saudara-saudaraku...

Pernahkah kita terfikir akan sesuatu keaadaan yang tidak diberitahu bila 'dateline'nya? Sesuatu yang pasti akan hadir tetapi tidak ada sesiapa pun yang tahu bila ia akan berlaku. Setiap daripada kita pasti akan menghadapinya. Apakah itu?

Ya, itulah mati.

Kematian itu akan kunjung tiba.

Kematian itu pasti.

Kematian itu tiba-tiba.

Tiada siapa yang tahu bilakah akhir waktunya.

Tiada siapa yang tahu bagaimanakah keadaan akhirnya.


Kematian itu boleh hadir bila-bila sahaja. Tidak kira kita tua atau muda, kaya atau miskin, ketika dalam keadaan beribadah dengan amalan ahli syurga, ataupun bermaksiat bak ahli neraka.

Jika kematian itu akhir segalanya, maka kita boleh bersahaja dan duduk berpangku tangan menggoyang kaki. Namun hakikatnya tidak begitu.

Kemudian, sesudah itu, sesungguhnya kamu sekalian benar-benar akan mati.
Kemudian, sesungguhnya kamu sekalian akan dibangkitkan (dari kuburmu) di hari kiamat.
[23:15-16]

Sekarang bayangkan, jika Allah membukakan rahsia kematian, dan diketahui tarikh mati kita adalah esok, tepat jam 1:30pm. Apa yang akan kita lakukan?

Cepat-cepat cari sejadah, berdoa sebanyak-banyaknya, solat sebanyak-banyaknya, minta ampun daripada Allah agar segala dosa diampuni dan berharap diganjari syurga. Sepanjang malam akan didirikan ibadah qiamullail. Mata yang tidak pernah basah mengingati dosa bercucuran dengan air mata. Segala kenikmatan dunia yang dibangga-banggakan terasa langsung tidak bererti.

Harta, pangkat, kemahsyuran, teman, kekasih...semuanya sirna begitu sahaja.

Apa gunanya memiliki semua itu sedangkan di akhirat kita tidak kembali kepada Allah dengan hati yang bersih?

(yaitu) di hari harta dan anak-anak laki-laki tidak berguna,kecuali orang-orang yang menghadap Allah dengan hati yang bersih,
[26:88-89]

Namun begitu, tiada di antara kita yang akan mengetahui bilakah masanya kita akan pergi.
Bagaimana rasanya apabila kita dihadapkan ke mizan lalu dikatakan kepada kita :

"Maaf, timbangan amal anda tidak cukup untuk ke syurga."

Dan barangsiapa yang ringan timbangannya, maka mereka itulah orang-orang yang merugikan dirinya sendiri, mereka kekal di dalam neraka Jahanam.
[23:103]


Maksudnya sudah pasti kita akan ke neraka! Na'uzubillah min zalik!





Sanggupkah kita menghadapinya? Kenyataan apabila kita sesungguhnya bakal dihadapkan ke neraka yang amat mengerikan. Keadaan yang tidak sanggup dihadapi oleh sesiapapun. Allah menggambarkan kengerian yang dialami bagi mereka yang dihadapkan ke neraka dalam firmannya:

Dan (alangkah ngerinya), jika sekiranya kamu melihat ketika orang-orang yang berdosa itu menundukkan kepalanya di hadapan Tuhannya, (mereka berkata): "Ya Tuhan kami, kami telah melihat dan mendengar, maka kembalikanlah kami (ke dunia), kami akan mengerjakan amal saleh, sesungguhnya kami adalah orang-orang yang yakin".
[32:12]

Ketika itu baru hendak bertaubat, ingin mengerjakan amal soleh, ingin dikembalikan ke dunia. Sesungguhnya semuanya telah terlambat. Segala dosa maksiat yang dipandang remeh di dunia berubah menjadi sesuatu yang amat menakutkan di sana. Mereka akan dibakar berterusan sehingga hangus, lalu digantikan dengan kulit yang lain.

Sesungguhnya orang-orang yang kafir kepada ayat-ayat Kami, kelak akan Kami masukkan mereka ke dalam neraka. Setiap kali kulit mereka hangus, Kami ganti kulit mereka dengan kulit yang lain, supaya mereka merasakan azab. Sesungguhnya Allah Maha Perkasa lagi Maha Bijaksana.
[4:56]

Bayangkan bertapa dahsyatnya azab itu. Sedangkan api di dunia inipun kita tidak tertahan akan panasnya, inikan pula api neraka, yang panasnya 70 kali ganda!


Jangan sehingga kita menjadi seperti golongan ini:

Dan orang-orang yang kafir kepada Tuhannya, memperoleh azab Jahanam. Dan itulah seburuk-buruk tempat kembali.


Apabila mereka dilemparkan ke dalamnya mereka mendengar suara neraka yang mengerikan, sedang neraka itu menggelegak,
hampir-hampir (neraka) itu terpecah-pecah lantaran marah. Setiap kali dilemparkan ke dalamnya sekumpulan (orang-orang kafir). Penjaga-penjaga (neraka itu) bertanya kepada mereka: "Apakah belum pernah datang kepada kamu (di dunia) seorang pemberi peringatan?"


Mereka menjawab: "Benar ada, sesungguhnya telah datang kepada kami seorang pemberi peringatan, maka kami mendustakan (nya) dan kami katakan: "Allah tidak menurunkan sesuatu pun, kamu tidak lain hanyalah di dalam kesesatan yang besar".


Dan mereka berkata: "Sekiranya kami mendengarkan atau memikirkan (peringatan itu) niscaya tidaklah kami termasuk penghuni-penghuni neraka yang menyala-nyala".


Mereka mengakui dosa mereka. Maka kebinasaanlah bagi penghuni-penghuni neraka yang menyala-nyala.
[67:7-11]

Tatkala menghadapi azab, barulah menyesali perbuatan. Ketika itulah menyakini segala perintah Allah itu wajib diikuti, setiap laranganganNya wajib ditinggalkan. Di saat itulah beru hendak berasa rugi kerana tidak mendengar nasihat mereka yang memberi peringatan dan menyesal kerana mempermainkan peringatan-peringatan.





Mari kita kembali. Kembalilah kepada Allah sebelum segalanya terlambat. Masih ada masa untuk kita. Pintu taubat masih terbuka. Berusahalah sehabis baik untuk menggapai syurga, paling tidak pun, berusahalah menjauhi neraka. Sungguh, tiada siapa yang mampu untuk menghadapinya. Sedangkan syurga itu penuh kenikmatan dan kebahagiaan. Biarkan diri kita tersiksa dan merana di dunia kerana ingin menjadi hamba Allah yang taat, kerana semuanya akan sirna dengan kenikmatan syurga yang bakal dimiliki.





Semoga kita akan mendengar panggilan rahmat ini kelak :

Hai jiwa yang tenang.
Kembalilah kepada Tuhanmu dengan hati yang puas lagi diridai-Nya.
Maka masuklah ke dalam jemaah hamba-hamba-Ku,
dan masuklah ke dalam surga-Ku.

[89:27-30]

"Ya Allah, ampunilah hamba-hambaMu ini. Seringkali kami melupakanMu. Seringkali kami bermaksiat kepadaMu. Kami lebih mencintai dunia daripada diriMu. Namun jauh di sudut hati sebenarnya kami mengharapkan cintaMu. Cintailah kami Ya-Rabb."

Sebuah Pengakuan

Tuhanku... aku tidak layak memasuki syurga Firdaus
Dan aku pun tak mampu menahan siksa api Neraka

Terimalah taubatku dan ampunilah dosa-dosaku
Sesungguhnya Engkaulah Pengampun dosa-dosa besar


Dosa-dosaku amatlah banyak bagai butiran pasir
Terimalah taubatku, wahai Yang Maha Agung


Umurku berkurang setiap hari, sedang dosa-dosaku terus bertambah
Bagaimana aku sanggup menanggungnya?


Tuhanku... hamba-Mu yg durhaka ini datang bersimpuh menghadap-Mu
Mengakui dosa-dosa dan menyeru memohon kepada-Mu


Bila Kau mengampuni, Engkaulah Sang Pemilik Ampunan
Bila Kau campakkan aku, kepada siapa aku mesti berharap selain dari-Mu?