Category: Engineering

Categories
Engineering Projects

Loading 7.5mm 1882 Ordnance: My Process

Author’s note: I posted this on a
local reloading forum. I am reproducing it here in the hopes that someone trying to do what I did can learn from my experience.

I recently bought a Model 1887 Swedish Nagant and I of course wanted to shoot it. This revolver shoots 7.5mm 1882 Ordnance. It
was used by the Swiss and Swedish, so you will see the country names used interchangeably when searching for information online. You can buy smokeless powder rounds from a few specialty places, but I wanted to shoot a round as close to the original as I could,
which means its time for the holy black. I also get weirded out shooting smokeless powder in guns designed for black powder. To that end, here is how I went about loading 7.5. As always, you take your life into your own hands following my instructions. I could not find any load data in my books so my process is an amalgamation of everything I found online.

First I bought a bunch of 32-20 brass. This is going to be our parent case. I have a Lyman universal trimmer with an adapter for a power drill which I used to trim the cases down. Go slow and trim each case to a length of 0.89 inches. You especially need to be careful as you trim past the shoulder on the case. If I went too fast the cutter would push the last end of the shoulder into the case and mess up the case. After all the cutting was done I used a case prep tool to clean up the mouths.

Once you have the cases prepped, you are going to need some bullets. I went with 310 Cadet bullets from  Matt’s Bullets. These are heeled bullets like the original cartridge uses. Ideally I would have bought the mold, but the molds were going for $70 or so and you can get 500 bullets for a little less than that (lubed too). Diameter wise it is between the original Swiss (.315) and Swedish (.327) bullet diameter.

Now you are ready to reload. For my load I used CCI small pistol primers and 11 gains of 2F black powder (GOEX) topped off with a .32″ diameter, .025″ thick card from Track of the Wolf. Ideally I would have liked to put a lube disc on top of the charge and before the card, but there was not enough space left in the case. I did not use a drop tube, but you could probably ring some more space out that way if
you had one.

Now, you could spring for the correct 7.5 dies, but they were pretty
expensive and hard to find, so I jury rigged a solution using some cheaper dies. I seated the bullet using a 32 short (32 S&W) seating die. Do not press too hard or you can crush the case given this is a heeled bullet. Once the bullet is seated I put a riser on the press like the ones you find in a bullet resizing kit. Then I screwed a 30-30 WIN crimp die all the way down. If you put a bullet on the riser you can get it high enough into the crimp die to crimp the bullet in place. You need a crimp or otherwise I found you could easily pull the bullet out with your hands. Running the crimp die all the way down probably gives you more crimp then you need, so your may want to experiment with a little less crimp than I used.

Shooting wise, it seemed a little anemic, but it went bang. I am not a great shot with revolvers, but it was hitting the target at 10 yards so I was happy.

Categories
Engineering Java

Your System is Finite

Let us talk limits for a bit. No, put away your graphs, this is about memory
limits. Before I get into the discussion, a few notes. I am going to be talking
mostly about particular errors and operations in Java. A healthy knowledge of
the Java Virtual
Machine with particular attention to
garbage collection and heap allocation would be useful.

Recently I encountered some issues where our application was running out of
memory. In this case the Java virtual machine is going to throw this exception:
OutOfMemoryException.

Why is this happening?

When your program runs in the JVM the JVM has a specific amount of memory (a
subset of the system’s ram) it can use to allocate objects. This area is the
heap and it is where all the objects you create using the ‘new’ keyword will
live. Stuff like this:

CustomObject customObject = new CustomObject();

The amount of heap space the JVM has access to is based on the system it is
run on. The JVM will set the amount of heap space available to it when it
starts. As your program executes, the JVM will allocate space on the heap for
objects the program needs. Objects you no longer need will be removed via the
JVM’s garbage collector. The garbage collector however, cannot remove objects
still in use. Therefore if you create too many objects you will use up all the
heap space and get an OutOfMemory exception. This is the key point: your
system is finite.

For example, if your heap size is 256MBs and each object you create takes
1MB then code like this:

CustomObject customObjArray =
getNumberOfCustomObjects(257)

Will require at least 257MBs which you do not have. Thus the JVM cannot
continue and it throws an exception.

How Can We Fix This?

Now there is an easy fix to this. When you start your java program you run
it on the console like this:

java myProgram

You can specify
arguments on java to increase the heap size. Specifically something like
this:

java -Xmx:1g myProgram

This would set the JVM’s heap size to 1 gigabyte. Do not do this! It is
tempting, it is easy, but it covers up an underlying problem in your program.
Now, of course, there is a time and place for this, but for the most part all
you are doing is delaying the problem, forcing future you to deal with it.
Future you will hate you for it. Let us look at a close to real life
example.

Record recordArray =
getAllRecordsFromMySql();

This is perfectly valid code. All we are doing here is getting a bunch of
objects back from the database. Simple code can get you into a lot of trouble
if you do not have a good understanding of how many records you can get back.
We have three possible cases here:

1. We get 0 items back.

2. We get n items which consumes less than the total heap size.

3. We get n items which needs more heap than we have.

In the first case, we are fine, no issues there. In the second case we are
also fine. You may not even have to worry about that if the number of objects
you expect back is always (key word) going to be be less than your heap size.
For example if our app can only ever store 10 records at a time (like a
rotating log) we will be fine. If, as I saw recently, the number of records you
could get back is near to unlimited then I can promise you at some point that
is going to happen. You can then see that it does not matter what we set our
heap size to. If the amount of records are bound to the size of system’s hard
disk then, at some point, the amount of stored records we have will exceed the
total amount of available ram and then it does not matter what you set the
JVM’s heap size to, you could not possibly set it high enough and your program
explodes.

What you can do however is limit the amount of records you process at one
time. Consider a couple different strategies for this case (reading n entries
from a database).

1. Conditionally Limiting your Mysql query to a certain id range.

If your tables are setup correctly it is possible you could get your rows
based on increasing the id. For example you could execute a query like
this:

select * from records where id >= 0 and <= 500;

This would get all your records with ids from 0 to 500, or 500 records.
Assuming ids are unique (meaning two rows cannot have the same id). Then you
could iterate your id range and get the next 500. Keep doing that until you
have less than 501 results and you have processed all your results.

2. Using a cursor

A cursor is basically an iterator. It points to one row in your database.
From there you can move to another row. You are only allowed to operate on one
row at a time so you will never run out of memory. This can be especially
useful if you want to process a large number of objects, and then update them
in the database. Code that would look like this:

while(mysqlCursor.hasNext()) {

       Record record = mysqlCursor.next();

       processRecord(record); 

       writeRecordToTable(record);

}

Both strategies will limit the amount of data you have to manage at any one
time.

Key Takeaways

The key rule to remember here is, when working with computers, you are
always working with finite resources. Memory has limits. You can program around
them easy enough, but they are there and they must be respected.

Categories
Engineering Philosophy

Impatience is the Mind Killer

I am not a patient man. It is one of the main reasons I went into software
engineering. It is very quick to think of an idea and convert it to machine
language. This desire to do things as quickly as possible has served me well in
that past, but lately it has caused great harm. An example and then an
explanation. I have been working on some systems at work that require a lot of
tinkering with some of the special database sauce we use. An unfortunate side
effect of this development is the need to constantly replace rpms (a kind of
specialized automated zip file). I was having great difficulty getting the
system updated with my changes so in my haste I just uninstalled all the rpms
of a particular package so I could reinstall all my newly built ones. Of course
what I should have noticed was I was uninstalling rpms that I had not built new
versions of. There is a sudden clarity when your console stops accepting
commands. In that brief window before you get told for certain that you lost
your connection you curse the gods, which for me happen to be the trinity of
Richard Stallman, Dennis Ritchie, and Ken Thompson. As you can surmise the
system died a quick death. And since the issue I was working on was hardware
dependent I had to develop on an actual blade instead of a virtual machine so I
had no snapshots or backups to revert to. Thus the afternoon was lost to
resuscitating the system via the HP ILO system and
its fantastically poor console. It was a huge pain, a waste of time, and
ultimately did no good to helping debug the problem. The solution it turns out
was far more targeted, I just needed to update a few system files instead of
blowing out all these rpms. So what is to be learned from this? Be patient and
be sure of what you are doing before acting.

The thing is, I used to get by wielding a giant hammer but I need to be more
comfortable with the scalpel. If I had just taken the time, talked to people
who knew the issue, and acted with a bit more foresight I could have saved
myself much gnashing of teeth. I chose an engineering example as I tend to like
thinking with that discrete mindset, but the lesson should be applied
elsewhere. The problem with impatience is its side effect, anxiety. I have been
kind of obsessed with grand schemes that can be rapidly achieved. Then,
inevitably, when things begin to drag I grow agitated that my plans are not
proceeding with the rapidity I prefer. Take my house hunt for example. Many
dreams, little progress in resolving them. I could buy a house tomorrow, but,
given the options available now, it would be a poor call. Rationality in
conflict with impatience creating anxiety.

Not sure how to resolve the quandary. Engineering-wise the solution is
simple: be more deliberate in action. I should work harder to understand the
systems I work with and only make the smallest possible changes at a time.
Personally though it gets harder to fix. If I do all I can to achieve something
and yet it remains unachieved the only result can be frustration. The beauty of
software is understandable systems where input produces expected output. When I
expect the same from the world disappointment will abound. Impatience is just a
byproduct of this unfortunate truth. It is as if I am desynced from reality,
like we are running on separate clock cycles. I expect one
speed of progress and get another. In time I hope to sync up, but until then I
remain impatient.

Aside: I goggled this title before using it and seems I was not as clever
as I thought. A regrettably common occurrence. I still like it though so I
am going with it.

Categories
Engineering Philosophy

The 24Hour Programmer Lifestyle

I was on Imgur today and saw the “we’re hiring!” link in all red. Had to
click it. Look at the position closest to my skill set here. Pretty standard, including this
little blurb at the bottom:

if you’re passionate about coding or design, then we bet you have lots of
things that you’ve done in your spare time. Along with your resume, we’d like
you to send us some samples. They can be personal projects you’ve whipped up
during a lunch break, or a full-fledged application that you’ve created from
scratch.

I am going to coin a phrase here and call this the ’24 hour programmer’. The
kind of gal or guy for whom coding is akin to speaking. They read technical
journals for breakfast, listen to programming podcasts during their commute,
work a full day banging out code, and then go home and work on their open
source projects. I have had the pleasure of knowing some of these people and
they are very good at what they do. This is not how I operate. I give my
employer 8 hours (or so in either direction) and then I go home and do
something else. I may on occasion drop some code outside of the office, but I
have other non-technical interests. It may surprise my employer, but I do not
think of code all my waking hours. I do other things, like build costumes, or play
video games, or try and meet other people. It is a
curious perversion of the tech sector that we expect engineers to always being
engineering. Do we expect carpenters to always be building stuff? Is an artist
somehow less dedicated if they occasion to not draw or paint one day? Maybe the
peculiarities of the startup culture have somehow equated people who live code
all the time as the ideal programmer. Everyone else who does not do the same
must just not be into it. They probably just do it for the money. There is
another word for this: elitism.

Employers, do not pigeonhole yourself looking for these people. Yes they
probably make good employees and yes they might even be better, but you ignore
all the other equally good employees who do not act like this. In any field you
are going to have people who are solely focused and you will have others who
who have many focuses. Staff your company with the best employees, not just the
ones who live a certain lifestyle.

Categories
Engineering Philosophy

Technology is Hope

I recently saw this
TED talk and it really crystallized why I love technology so much. Go ahead
and watch the talk before you read this post, or not in which case I will sound
far more original than I might otherwise be.

Have you watched it? Good.

The main thesis of Professor Herr’s presentation is that people are not
disabled, instead their technology is insufficient for their needs (14:25 in
the video). This turns out to be an incredibly potent idea. Before disabilities
like deafness, blindness, loss of limbs were permanent conditions. There were
no solutions. Through time and effort humanity was able to build crutches or
stop gaps. Hearing aids, peg legs, crude imitations of the organic components
they were replacing. This was all that could be accomplished at the time and
this is why we considered people disabled, because there was no way to fix what
was broken with them. Their condition was permanent. Professor Herr shows us
differently. By taking an incredibly hard problem (replicating a human leg) and
applying his skill and that of his team they were able to produce a very close
facsimile to a human leg. Is it a perfect replica no, but it is a start on a
long journey. And unlike our legs, his team’s work is constantly improving and
will (I have no doubt) eventually surpass our own organic ones. This work
proves that people are not broken we just have not developed the technology to
fix them.

Why does this show how much I love technology? Because the root of Professor
Herr’s philosophy is ultimately the belief in a better world. Not just hope
that things will get better, not just a faint hazy dream of an improved future,
but a real steadfast unshakeable conviction that the world is becoming better
through improvements in technology. And in true empirical fashion he asks us
not to take that conviction on faith, but on the real concrete evidence he
presents. Do not underestimate the power of this ideology. Embrace it and make
it part of your identity. I do not just believe, but I know that humanity grows
its knowledge daily, cultivated by the work of all of us to push ourselves and
our technology inexorably forward.

When I say I love technology I really am just saying I love humanity’s will
to better themselves and our world. I love our intellectual strength that we
wield Thor like to crush the problems of our ancestors. Can you imagine how
things used to be? How our species used to be hobbled by inefficiencies, by
disease, by the dark. Technology is that great shinning light in the distance
illuminating the future for us.

We have not solved all our problems yet, but we can and we will. No gods
will rescue us, our own will and might shall be our salvation.

Categories
Engineering

Why You Should Not Expose Your Failed SQL Query

It is the weekend and as I am wont to do I pay a visit to warez-bb.org. A site focusing on links to
illegal file distribution. They do have some legal links, but it would be a lot
like drug dealers selling candy on the side. Not really their purpose for
being. Anyways the site was down as usual. Seems their host is just generally
bad as this is a common occurrence. Today was different though. It was serving
a relatively unique error.

CleanCapture

What are we seeing here?

This is the exact SQL query
that the server was trying to run which failed for some reason. In other words
when I tried to access the site the server tried to (via the sessions.php file)
create a user session for me within its database. This session would then track
my usage of the site. Not sure exactly what, but possibly how long I use the
site, pages I go to, posts I make, etc. That session creation failed for some
reason and it returned this error to me.

Why is this significant?

This is a significant error as it exposes information the user (client)
should not be aware of. Specifically a database table and columns in that table
that the server uses. This is important because it makes my job easier if I am
looking to exploit the system.

How could I do that?

Let us look at the error we got back. I have highlighted the important
sections here:

EditedCapture

This gives us two pieces of important information:

  1. That the site knows my username (which I have removed).
  2. That the site is using a particular id number to identify me (the red boxes
    which represent the ‘session_user_id’).

How does the site know my username if I have not tried to login (this is the
first thing I see on accessing the site)? The site has checked for an existing
login cookie on my machine. Lucky for us we can look at that cookie and see
what information it is providing. Let us open up firebug and take a look.

WarezzBBCookie

See that red box. That is the same number we are using in the failed SQL
query for the ‘session_user_id’ column. Let us go ahead and use firebug to
change that number and see what happens:

FirebugCookieChange

Luckily for us warez-bb operates sanely in this regard and my attempt to
exploit failed. You can see it just reverts to an anonymous user. That stills
gives us some useful information on how the site operates though. It must be
using the ‘session_user_id’ contained in the cookie, and those other values to
retrieve my username which is not saved in the cookie. Another attack vector
which I did not consider is instead of just changing the ‘session_user_id’ in
the cookie is to inject
SQL into its spot instead. The idea would be the server would execute the
SQL command I provided in the cookie. Based on the result of the first test it
is likely warez-bb defends against this attack by sanitizing whatever input it
gets back from cookies.

Though my attacks failed this is still bad practice. The user of a site
should know nothing about the underlying operation of your server. Any
information you unwittingly provide makes the attackers job easier.

Categories
Engineering Philosophy

Digital Legos

Sometimes I get anxious, antsy. Spend too long in meetings or clearing out
emails.Sometimes I just want to code. It is akin to an addiction. Do it too
much and you overdose and your quality suffers. Do it too little and you go
into withdrawal, just begging to get that next hit.

Consider this metaphor. In Homeworld the various races travel
around space by means of hyperspace jumping. For all races except one this is
just another form of faster than light travel. For the outlier race, the
Bentusi, it is different. For them Hyperspace travel is an experience, a reason
to live. By their own account, “hyperspace sings in our
ears”. So to is coding to the programmer. To live is to program. You cannot
separate the two.

What breeds this addiction? This affliction differs from person to person,
but for me it has always been to play. Code is just another toy for me, like
legos or Lincoln logs. It is about challenging yourself to make interesting
unique work with the pieces you have. I have a bunch of loops and conditional
statements and variables how can I make a list of unordered numbers become
ordered? How can I make it run fast? How can I make it use space efficiently?
You do not need any special education, all you need is the will to learn. You
can do that right now. Do not even leave this blog page. Go ahead and pop open
the web developer tools (Ctrl+Shift+K for Firefox, F12 for Chrome and IE. Press
Ctrl + 2 after opening up the development tools in IE to get the console). Play
with some javascript right now by typing at the prompt the following and
hitting enter:

alert("Hello World")

This creates a simple popup with “Hello World” displayed. Neat huh, not very
flash but you just did something. Try something else, type this and hit
enter:

confirm("See Some Buttons?")

This creates a similar popup but with an ‘Ok’ and ‘Cancel’ button. Are you
feeling it yet? Play with some math, go ahead and add some numbers at the
prompt:

3 + 3

It adds them for you and shows the result. You can multiply and divide and
all sorts of fun math stuff. Remember my example of turning unordered lists
into ordered lists. That is a solved problem for us. Look at this:

[1,5,2,3,6,7].sort()

What do you get? The numbers come back in sorted order. Try putting some
words in there and see what happens:

["bear", "cat", "chair", "apple"].sort()

Was that fun for you? It is not everyone’s jam, but I live for this. I live
for the thrill of trying to solve problems and build things with all these
digital parts. Its exploration, its discovery, its adventure. For some people
it is just a way to get around, but for others it can be a real journey.

Categories
Engineering Philosophy

Why I Love Documentation

Documentation is an extension of the engineering process not an afterthought
or a separate process. When I say documentation, I am referring to the text you
produce that gives an overview of how a project was done (architected) and, in
some cases, how to go about using something. I am not talking about inline
documentation like code comments. When you document a project you are seeking
to answer two questions:

  1. Do I understand what I just did enough to explain it?
  2. Upon review, can I improve what I just did?

The first question challenges you to actually explain what you just did. If
you were explaining a feature you wrote you would talk about how all the moving
parts fit together. To put it a little more concretely you explain how certain
classes/objects interact with other classes/objects, how you went about
segregating your work, what design patterns you did, how data flows from one
form to another. This is what people care about, because here you describe how
to actually use what you did. I am a huge fan of providing concrete, full code
examples of how something works. If you want to know how something works, the
best way to learn is to look at the code. This is extremely easy when the
person who wrote it provides a concise detailed walkthrough. A good example of
this would be the JDeveloper
ADF tutorial docs. Clear incremental examples walking through how to do
something complicated. If you can answer this question you prove to yourself
you fully understand what you just did. If you cannot answer this question you
will pay for it in the future, either in your inability to help others use what
you have written or the difficulty you face fixing a bug/adding a feature. Use
documentation to ensure you know what you are doing.

The second question is a byproduct of the first. While working through what
you just did you are also evaluating how well you actually did something. This
is akin to editing a completed work. I can only speak of my own experience, but
I have two working modes: producing and editing. When I produce I have a
limited view as I seek to solve small discrete problems one at a time. How do I
process this bean, where can I get this data, what SQL command returns the
proper set of data. It is only when I pull back out to editing mode that I can
take a broad view and see how my work integrates into other pieces. Why have I
not condensed all these similar business class function into one call, why did
I use a array in this data structure when a hash map offers a quicker lookup
time. When you are immersed in work it can be very easy to lose the larger
picture of what you are accomplishing. Only by reviewing what you have done can
you pull back and evaluate your creation.

This philosophy does not just apply to code. One of the guiding principles
of this blog is a venue for me to document my past project thoughts, like I
have done with my
helmet thus
far. I have found that the mere act of organizing the fractured thoughts into
ordered structured sentences can I better understand what I just did. It allows
me to understand the process I followed and determine ways I can improve it.
And that is the key to why I love documentation. Documentation is self directed
learning. This is your craft, it is worthless to practice a craft without the
desire for constant improvement. Use documentation as a means towards
constantly improving your craft.

For a more detailed, programmer centered overview, check out Yevgeniy
Brikman’s post on the subject.

Categories
Engineering Philosophy

Your Responsibility as an Engineer/Doer of Things

Have you ever looked over your job responsibilities? Here is an example
listing of some responsibilities of a software engineering position:

Responsibilities:

  • Application design from concept through development and implementation
  • Provide technical leadership and guidance to your team members
  • Establish a solid project framework and excellent development
    processes
  • Consistently deliver quality software and services
  • Work with internal and external teams to co-ordinate parallel development
    efforts into single releases

Lot of stuff in there, but if you filter out all the buzz words and business
speak you really only have one responsibility, the most important rule for any
project: GET THINGS DONE. This may seem obvious, but it is so easy to get
bogged down in the implementation of something that you lose sight of this
goal. Look at some important coding practices:

  • Code makes sense to people reading it after you (consistent style, clear
    function/variable names, obvious segregation of tasks).
  • Code is free of extraneous variables, function calls, bad comments.
  • Your algorithms are as time and space efficient as can be.

But what is that list missing:

  • Code must work.

It does not matter how efficient, clean, nice your code is. If your code
does not work you fail, do not pass go, do not collect $200, go to jail. Sure,
try and follow all these goals while you are working. In fact a good engineer
would actively be following them all the time. But, that said we live in world
with time tables and deadlines. No one and I mean absolutely no one cares about
anything else if your code does not work when they need it to. It is the same
concept when working on building something physical. Stop getting held up on
getting things perfect, do the best you can in a reasonable amount of time and
move on. Perfection is for finished working things, not for projects in
progress.