I'm thinking about toying with the idea of maybe doing some hacking on the Arduino IDE. So I made a local clone of their public Git repository:
So far it's pretty basic stuff; from here I can hack on the codebase, commit my own changes, etc. Importantly, I can keep my local copy of the codebase up-to-date with changes from the official site via a
as the official site is listed in my config as the origin remote site. What I can't do is push my changes (via a
Since I'm looking at adding new features, I'm going to create (and move to) a new branch (named "windshield" for mysterious reasons) in my local repository:
Still pretty basic. From here on, any changes I make will be part of the windshield branch and won't pollute the master branch until I merge them. This should help with pulling official updates as well.
Now where it gets weird is I want to back up my changes to a different remote repository, one hosted at my workplace (it is, after all, a work-related project). So first I set a new remote named "uwg" that points to the arduino-windshield project I created at our Gitlab site, and then set the local windshield branch to push its changes to that remote:
Now, as long as I am working on the windshield branch on my local machine all my commits will go to my work repository when I issue a
Half-Life 1 and 2 rank among my all-time favorite video games. HL1, especially, has a great story, which is hard to pull off in a first-person shooter. Being a science fictional setting, there's a lot of fantastic stuff that requires suspension-of-belief: murderous monsters, teleportation portals, alien worlds, futuristic technology, and the fact that all the scientists at Black Mesa have the same face and voice. Given all that, there was one that actually bugged me: the fact Gordon Freeman, the protagonist, could carry several hundred pounds of weapons and ammo and run sprints without breaking a sweat. To recap, by the end of HL1, Gordon is carrying:
Not content with "it's just a game, stupid" my brain has rationalized how one Navy-Seal-turned-high-energy-physicist could carry all this, and what's more, it's actually a major plot point.
The key is the HEV Suit. If Gordon Freeman is the archetypal hero of myth, the HEV Suit is his magic armor. It protects him from injury, aids healing, allows him to run faster, keeps track of vitals and ammo, talks to him in a friendly robo-feminine voice, and even has a handy flashlight. It is what sets Gordon apart from other actors in the game, what gives him power beyond mere mortals.
And it's why the military is after him.
We are told in the beginning that the HEV suit is merely work clothes, something a third-tier physicist wears while doing the grunt work for the Big Name scientists at Black Mesa, all the while hoping he'll be listed as fifth contributor on a journal paper or three. That just what we're told. In reality, it's a prototype military exo-suit, outfitted with advanced technology gleaned from Black Mesa's dalliance with portals. Specifically, it uses portal-based technology to create extra-dimensional "pants pockets" where Gordon can stash his arsenal without being encumbered. Doctor Who would be proud, possibly even jealous.
It's pretty clear the suits are rare:
Given how powerful the suits are, it's no wonder the military wants them. And it's quite possible Gordon has the only one left on Earth. So when the soldier come in and start murdering scientists left and right, they aren't just securing the facility and erasing every trace of Black Mesa's existence. They're also after control of all the cool weaponized tech -- including Gordon's HEV suit. I mean, they wouldn't want him getting away and selling it to Aperture Science, now would they? And in the end, they get it, or at least, the G-Man gets it when Gordon agrees to be his flunkie and go into suspended animation for 20 years while the Combine invade and enslave us all.
Fortunately the other Black Mesa survivors (likely Dr. Kleiner or Dr. Vance) were (conveniently) able to re-build a new HEV prototype just in time for Gordon to re-awaken in HL2. At that point the world is already conquered by forces with much cooler toys, so Gordon is pursued less because he's wearing a mechanical orange jumpsuit and more because he's a frickin' Buck Rogers, a legendary hero come back from the dead to lead us out of slavery. If he doesn't hog all the medkits, that is.
I'm not ashamed to admit Ruby messes with my head. I'm pretty much an ice-cold master of C, Java, and (mostly) C#, but I feel I've only scratched the surface of Ruby.
So my trick of the day comes from trying to think up a way to unit test a Ruby module with non-module methods, meaning it has to be mixed-into a class before those methods can be called and tested. My first pass was simply to write a throw-away Ruby class that mixed-in the module. But then I though, why not make a function that works for any module?
So I actually wrote two functions:
Here's the code for the first one. All it does is create the new Class object, passing as its body an include statement for the module.
And the second, which simply calls new on the class created from the previous function:
People who know me know I'm a fan of Joss Whedon's short-lived TV show Firefly. I was thinking about one episode in particular today, titled Out of Gas [Spoiler warning: link goes to plot synopsis]. Their spaceship is dead in the water, er, space. Captain Malcolm "Mal" Reynolds divides the crew into the two short-range shuttles, sending them in different directions in the desperate hope that one will come across help. In case that happens, Mal is staying with the ship so he can call the other shuttle back.
So what does this have to do with UI design? Wash, the ship's pilot, recognizes that Mal will need a way to call the shuttles back, so he comes up with the most user-friendly solution he can think of: he jury-rigs a big red button onto the radio. Mal doesn't have to worry about radio frequencies, tuning, electronic jibber-jabber, etc. He just has to push the giant, red, candy-like button. It's beautiful UI: simple, low mental overhead, no fiddling around necessary.
So I'm reading this post on an apparent 2003 attempt to insert a backdoor into the Linux kernel. In the post, he shows the bit of code in question:
and, in a parenthetical, asks the C-savvy readers to explain the subtleties of what's going on...with answers at the end of the post. I haven't read the answers yet, so I'm going to post my analysis, then compare with Dr. Felton's once I finish the article.
First off, the
Third, a lesser-known property of the
So, put those together, and we have a flow through the if-statement that goes:
And that's it. Note that the body of the if-statement,
Now I know next-to-nothing about the internals of the Linux kernel, but I know enough, in general, of systems administration to know:
So let's find out. According to Wikipedia, my first guess was correct; UID 0 is the root (superuser) account. In other words, the backdoor code has the effect of giving the backdoored program root-level access to the system whenever
My intention had been to stop there and see what the remainder of the post had to say, but my curiosity is getting the better of me. I want to know the context of those "options" and what they really mean. It appears
Now to see how close I got...and the answer is pretty much that I nailed it (high-fives self). Felton does mention that "So the effect of this code is to give root privileges to any piece of software that called wait4 in a particular way that is supposed to be invalid," and I don't know enough about the kernel to understand why
Apparently I'm all bloggy today. Fits and spurts, I suppose.
One thing I see occasionally is that Java's AWT/Swing Layout Manager system is an example of the Strategy design pattern. The more I learn about layout managers (and Strategy), the less I agree.
First off, a review of Strategy. The relevant highlights are:
To me (and I'll welcome someone pointing out where I get this wrong), the heart of the Strategy pattern is the ability to swap-out one implementation for another -- and have the user (client) of the Strategy be none the wiser.
Now, on to layout managers. In Java, there are two interfaces, LayoutManager and its extended interface LayoutManager2, that specify how layout managers should behave. Looking at the methods required by LayoutManager only, I'm actually comfortable calling it Strategy. So any class that implements only LayoutManager (but not LayoutManager2) should be interchangeable with any other that does the same...which basically leaves FlowLayout and GridLayout. It's important to recognize that both of these layout managers are agnostic of the Components being added to them; as a component is added, the layout manager finds a place for it.
LayoutManager2 breaks this component-agnostic system by incorporating the idea of constraints. Its addLayoutComponent() method allows implementing classes to associate a constraints object with a specific component in the GUI. An example is a constraint that says to put a JButton in the NORTH position of a BorderLayout -- the layout manager can't meaningfully position the JButton without this extra object that effectively couples the JButton (part of the layout manager's client, probably a JPanel or similar container) to the client.
As a more visceral example, create a JFrame with a bunch of buttons and labels and such and set its layout manager to FlowLayout. Then try to set it to BorderLayout or GridBagLayout. It might technically work, in a trivial sense, but you're missing out on the power of those layout managers if you don't go further and add in constraints. This violates what I see as the heart of Strategy -- that implementations of the algorithm be interchangeable.
All that said, this is not a critique of layout managers. Layout managers like GridBagLayout and SpringLayout are powerful and useful. I just don't think they can be called a Strategy pattern. My suspicion is that the original idea behind layout managers was that they were intended as a Strategy, but that the hard realities of GUI layout (especially with Java's can't-win goal of platform-independent GUIs) meant the API designers had to break it later on down the line.
As someone who grades student programming assignments, it isn't unusual to get a lot of rogue Java processes running in the background. Windows Task Manager is not good at distinguishing these from other processes that may be legit (like Eclipse itself); they all show up at "java" or "javaw" instances.
The Debug view (note: different from the Debug perspective) will show all processes (and their sub-threads) launched from within Eclipse, so it is a handy way to find out which student's work is, say, stuck in an infinite loop. Or didn't set the default JFrame close behavior as EXIT_ON_CLOSE. People who use the debugger regularly know this. The Debug View can be added to any perspective, so I put it in the regular Java perspective in order to keep an eye on what's running in the background.
I'd argue the Debug View is poorly-named, which may prevent people from finding it when needed. So maybe "The Goog" will index this for people trying to find the answer.
A friend who's been going to D*C far longer than I scanned in the 1988 program book. Geeky nostalgia...
I especially love the ads for vintage computer hardware.
Corrections/comments are very welcome, especially if I get the technical details wrong. Please email flippy.qa76 AT gmail.com.
If you are using servos with Arduino, sometimes the results can be...not what you expect. My example is that I was using continuous servos as the drive motors for a mini-sumo 'bot. The (greatly simplified) control loop for the motors looked like this:
And I'd get all kinds of wonky behavior, mostly in that it didn't appear the servos were getting any kind of speed updates at all. It was *supposed* to move straight forward when the sensor detected another object in front, but in most cases it would act as if the opponent wasn't visible. (And yes, I checked and double-checked that the sensors were working...)
It turns out this is a timing problem. Before I cut to the punchline, let's look at the issues in play here.
The first thing to look at is how often the
This page provides an excellent overview of the timing signals used to control servos. The TL;DR version is that a servo expects to receive a command to move (or in the case of continuous servos, to change speed) every 20 ms.
Now compare this to the
Next, consider what actually happens when a
The thing to understand here is that
One more thing to check -- how does the timer's period hold up to our assumption that we're sending servo commands every 20 ms? The answer is in
Fine, fine. In the end, you just need to make sure that you only call
From a code standpoint, this could be as easy as putting
In practice, I found that performing
1-10 of 89