Humble Pea & Ham Soup w/ Fluffy Dumplings

This recipe was originally posted at http://sundaysuppermovement.com/humble-pea-ham-soup-w-fluffy-dumplings-24-more-green-pea-recipes-think-spring/ but has since been removed. Posted here to keep it available for use.

Humble Pea & Ham Soup w/ Fluffy Dumplings

Prep Time 30 mins
Cook Time 2 hrs 20 mins
Total Time 2 hrs 50 mins

Ingredients
  

for the soup

  • 1-1/2 pounds smoked ham
  • 2 small onions small dice
  • 3 sticks celery small dice
  • 3 large carrots rough chop
  • 3 bay leaves
  • freshly ground black pepper
  • 1 pound green peas (fresh or frozen)
  • 3 sprigs rosemary leaves picked & chopped
  • zest of 1/2 lemon

for the dumplings

  • 1-1/2 cups all-purpose flour
  • 2 teaspoons baking powder
  • salt
  • 7 tablespoons unsalted butter cold
  • freshly grated nutmeg

Instructions
 

  • Remove the meat from any bone, skin, and fat. Cut into ¾" thick slices. Place the slices in a large, dep pan (at least 9" wide). Add onion, celery, carrots, bay leaves, and a smattering of pepper to the pan. Cover with 12 cups of water and bring to a boil over high heat. Put on the lid, then turn heat down to a simmer. Let cook for 1½ hours, skimmy foam every now and again.
  • While this is simmering, make the dumplings. Place flour in a bowl with baking powder and a pinch of salt. Using a box grater, grate your cold butter into the bowl along with a few good grates of nutmeg. Add about ¼ cup of cold water and then, using your hand, work everything into a ball of dough. It should be firm and fairly malleable. Add another drizzle or two more water if it seems to dry. Work quickly so that your body heat doesn't melt all the butter.
  • Dust a tray with flour and then divide the dough into 12 fairly equal pieces, roll into balls, and place on tray. Refrigerate until needed.
  • When cooking time is up, either pull your meat into shreds or pieces using a couple of forks or remove to a cutting board and use a knife. Return to pot. Bring back to a boil then add the peas, rosemary, and lemon zest. Plop in the reserved dumpling dough. Turn heat down to medium and allow to simmer for another 15-20 minutes to allow the dumplings to plump up and cook through.
  • Enjoy!

Penn Jillette’s Las Vegas Steak

On New Year’s Eve, I made this steak based on the description that Penn Jillette gave on an episode of Penn’s Sunday School. I surprised even myself when it came out so perfect and delicious! I hope you enjoy this recipe as much as I did.

Photo of raw steak

Penn Jillette's Las Vegas Steak

Prep Time 5 mins
Cook Time 12 mins
Total Time 17 mins
Servings 4

Ingredients
  

  • 2 lbs filet mignon or beef tenderloin steak
  • 1 cup brown sugar
  • 1 tbsp salt to taste
  • 1 tbsp freshly cracked pepper to taste
  • 3 tbsp olive oil divided

Instructions
 

  • preheat oven to 400 degrees
  • mix the brown sugar, salt, and pepper in a mixing bowl (make sure to taste it, as it should be delicious when the ratio is right)
  • coat the steak thoroughly in olive oil (massage it into the meat)
  • coat the steak with the brown sugar mixture
  • heat a large oven safe saute pan until just before it starts to smoke
  • add the remaining olive oil into the hot pan to coat
  • fold the steak onto the hot pan and let sear for 1 minute (fold away from you to avoid splashing)
  • flip the steak and let cook for 1 more minute
  • move the entire pan into the oven and cook until done (about 10 minutes)
  • remove steak from pan and serve

Updated site

I switched this site from Tumblr to a hosted instance of WordPress recently and I’m going to try to post a few times this year as a new year’s resolution for 2015.

Health Initiative 2015 is underway, but as a throwback to last year (before the diets of 2014) I will post a recipe for delicious steak based on Penn Jillette’s steak recipe.  Look for that in a few days.  In the mean time, please let me know if you have any questions, comments, ideas, etc. for the direction of this site.

Mac OSX 10.7 Lion problems

So when Lion came out last week, I went ahead and bought and downloaded it… I then spent 3 or 4 days trying to figure out why I couldn’t install it. I was also experiencing some problems with my installation of Snow Leopard and even trying to boot my known good Snow Leopard installer disk. The problems I was experiencing was that when booting up, it would completely freeze once everything came up and would sit like that for 5 minutes or so before I could start using it. Lion would not install stating only “An error has occurred, please run this program again later”

Only after I had been doing some searching for the errors that showed up in the installation log, I found a suggestion to try clearing the PRAM and NVRAM. I did that by turning on my Macbook Pro while holding down Option, Command, P, and R. And guess what, everything worked fine then.

So, my suggestion to any mac owners that are experiencing weird problems, reset your PRAM and NVRAM before you spend days searching for the answer like myself.

Experimental batch script

So, I was in need of using something like a pointer in a batch script, and I wondered if it were possible. So I invented this little script to demonstrate a cmd variable usage that resembles using pointers, or what is fun to say, variable variables. I’m not sure if it works using the command.com interpreter, but it does work with cmd.exe. Let me know what you think. I named the script varvarbinks.cmd

@echo off

:: setting up the pointer's value
set pntClient=%1
:: set the value of what pntClient points to
set %pntClient%=true

:: output what %%pntClient%% would equal since %%pntClient%%
:: does not work to a temp file
for /f %%a in ('echo %pntClient%') do set %%a>%temp%varvar.tmp
:: splits the variable and value up
for /f "tokens=1,* delims==" %%a in (%temp%varvar.tmp) do (
set valofvar=%%b
)
:: clean up the temp file
erase /F /Q %temp%varvar.tmp

echo The value of %pntClient% is %valofvar%


I wish I could get away with not using a temp file, but I haven’t figured out a way to do that yet. When you run, just run varvarbinks.cmd name-of-variable and it will show you that the name-of-variable is true.

AVG finds “Archive Bomb”

So, all of a sudden, AVG Network Edition (version 9.0.851 Virus DB 271.1.1/305) started to call a certain VBS file an “Archive Bomb”.

For any of you who do not know what an Archive Bomb is, it is basically an archive file (zip or rar, for example) that when decompressed, it takes up a LOT more space than the original file. This could be done by zipping a large file that is filled with all binary zeroes or ones. Another type of archive bomb is zipping a zip file, and then keep zipping the resulting file until when you try to decompress it, it will keep going until the last one. Both of these methods are designed to significantly hinder a computer when trying to decompress it. So, now after that background information, here is the script that AVG saw as an archive bomb:

ForReading = 1
ForAppending = 8

Set objFso = CreateObject("Scripting.FileSystemObject")
Set txtadd = objFso.OpenTextFile("k:\script\email\email.txt", ForReading)
Set filetxt = objFso.OpenTextFile("k:\script\notify\keybank.txt", ForAppending)
Do Until txtadd.AtEndOfStream = True
str = txtadd.Readline
filetxt.WriteLine str
Loop

txtadd.close
filetxt.close

That is it… no compression techniques used at all. We have been playing with the file, changing some of the basic structure of the script, re-typing the script into another file, etc… anyone have any theories as to why this would be detected as an Archive Bomb?

The big problem about this was when AVG found this file and thought it was a virus, it completely stopped processing everything on one of our main server machines that AVG was running on.

So, I believe this is one more reason not to use such anti-virus tools. The best one I’ve seen that doesn’t give such obvious false positives is Windows Security Essentials, it also doesn’t seem to stop any processes when files are found. But, of course, nothing beats the best anti-virus there is, the human brain.

WSH, RUNAS, Automation, etc…

Okay… So, I’ve been working on getting an automation script to work that runs a dos command as another user (namely Administrator) without requiring user interaction. So the RUNAS command is a good choice for a start.

One way to accomplish this is to download the program SANUR (runas backwords) and place it into your %PATH% and then use the command:

runas /user:CompOrDomainAdministrator Command to run | sanur password

That sanur command sends the password provided (could also place the password in a file so it is not immediately noticed) but this requires that you place SANUR into the %PATH% on all computers that will run the script, so lets try another way that also can help hide the password.

Here comes WSH scripting to the rescue. We can look at the Run, AppActivate, and SendKeys methods of the WScript.Shell object and use them to run the command, activate it, and then send the password to it.

First is the Run method. I would much rather use the newer Exec method, but for some reason, it does not seem to work with dos commands like runas and the like. Using Exec when possible would allow the AppActivate to be a little bit simpler by storing the WshShellExec object as a variable and look at the ProcessID property instead of the window title. But since it does not work quite the way we want, we use Run. The easiest way to do the run is (in JScript, I’ll add the VBS code in our final product):

var WshShell = WScript.CreateObject("WScript.Shell");
WshShell.Run("%comspec% /C runas /user:CompOrDomainadministrator CommandToRun");

That will create the WScript.Shell object and then use the Run method to run the runas command we spoke of earlier.

Now we have a window open running the specified command… now what? What if someone clicks away from it? That’s where the AppActivate method comes in.

WshShell.AppActivate("title of window" or ProcessID)

Okay, so we can use the title of the window we want to activate, or it’s PID. How do we get that? And if there’s more than one window with the same title, then what?

What I came up with was using the dos command TITLE to change the title of the running window and name it “Window” followed by a random number between 1 and 100000, so the chances of having two windows with the same name are very much minimized. But that chance does exist, which is why the WshShellExec.ProcessID method would be much better because a process ID can only point to one process. But this way gives us a better way than looking for “runas blahblahblah”. So here’s what we have so far:

var WshShell = WScript.CreateObject("WScript.Shell");
var strTitle = "Window " + (Math.round(Math.random()*100000) + 1);
WshShell.Run("%comspec% /C title " + strTitle + " & runas /user:CompOrDomainadministrator CommandToRun");
WScript.Sleep(1000);
WshShell.AppActivate(strTitle);

Note the WScript.Sleep(1000); That ensures that there’s enough time for the title and runas commands to start running. So now this works to open the command and activate the command’s window. Now it’s asking for the password (assuming you have one). Now lets plug it in with a call to the SendKeys method. SendKeys sends the string of keys to the currently activated window like the following:

WshShell.SendKeys("ThisIsAPassword~");

Notice the tilde (~) at the end. That is SendKeys‘ quick character to send an enter keypress or carriage return character. So now, we should have our completed code now. The following is the WSF file that contains the VBS and JScript versions of the same code:

`

Set objShell = CreateObject(“WScript.Shell”)
Randomize
strTitle = “Window ” & Int(Rnd * 100000 + 1)
objShell.Run(“%comspec% /c title ” & strTitle & ” & runas /user:CompOrDomainadministrator CommandToRun”)
WScript.Sleep 1000
objShell.AppActivate strTitle
objShell.SendKeys “ThisIsAPassword~”

var WshShell = WScript.CreateObject(“WScript.Shell”);
var strTitle = “Window ” + (Math.round(Math.random()*100000) + 1);
WshShell.Run(“%comspec% /C title ” + strTitle + ” & runas /user:CompOrDomainadministrator CommandToRun”);
WScript.Sleep(1000);
WshShell.AppActivate(strTitle);
WshShell.SendKeys(“ThisIsAPassword~”);

`

So there you have it. It will also work for windows programs as well.

But how about security? You definitely could just look at the script source and get the password, so there are two ways off hand to help secure the password. One way is to make sure the permissions on the file does not allow anybody other than those who would be using the script to read it. Or you can encrypt the script using Microsoft Script Encoder. But know that having it encrypted with that does not make it 100% secure. There is a VBS script out there that allows you to just drop any VBE or JSE file onto it, and it spits it all out in plaintext. So my recommendation is to use both security methods I mentioned.

Well, that’s all! I hope you all have fun with this information!