We are hiring software engineers and designers. We make our own desktop CNC machines and write software for the whole stack, from machine firmware all the way through to the browser-based design app, Easel. Our main focus right now is (1) making new ways of designing in 3D and (2) making the feedback loop between design, simulation and carving faster. That means lots of unique technical and UI/UX challenges.
If you are interested in design interfaces, how/why people learn to make, computational geometry, or if getting involved in educating the next generation of makers, we are looking to talk to you.
To me it is a combination of repetition and a confusing flow. It feels like it the author kind of discovered the interesting bits as she/he went. But I don't want to be a Criticizing Craig, so here is a (hopefully helpful) breakdown:
“When the voice coil is driven at the resonant frequency of the spring, the entire actuator vibrates with a perceptible force. Although the frequency and amplitude of a linear resonant actuator may be adjusted by changing the AC input, the actuator must be driven at its resonant frequency to generate a meaningful amount of force for a large current.”
Ok, got the basic principle and the key constraint (resonance) in the first paragraph.
“The voice coil remains stationary inside of the device while it produces a vibration and presses against a moving mass. By driving the magnetic mass up and down against the spring, the LRA as a whole will be displaced and produce a vibration.”
The first sentence feels like a repetition of the basic principle, but I get that (together with the second sentence) there is a subtle point being made: the whole assembly vibrates. I'd cut the first sentence or make the comparison more clear: “Although the voice coil is stationary within the LRA, … the LRA as a whole moves.”
The speaker comparison is good for illustrating the resonance constraint, but the conclusion simply repeats rather than expound on the principle. Leading the reader can make the implicit connection more obvious and avoid repetition: “While speakers can be driven at arbitrary frequencies, the physical spring within an LRA imposes a …”
“Rather than directly transferring the force produced by the voice coil to the skin, the device optimizes for power consumption by taking advantage of the resonant frequency of the spring. If the voice coil pushes the magnetic mass against the spring at the spring’s resonant frequency, the device can produce a vibration of higher amplitude more efficiently.”
This paragraph reintroduces resonance, but as an efficiency improvement. It feels repetitive, but there is an important point here that is left as a connection for the reader to draw: Offset rotating masses don't use resonance and draw much more power. I would actually use this in the leader. Instead of introducing resonance as a just a component of the system, make it the key. Instead of “that is DC and this is AC” (the impression I got from the first paragraph, lead with “that uses brute force and this uses a cool property of spring systems: resonance.” The latter is much more interesting, and can help reduce the repetition.
“Although the frequency can be changed, the LRA will typically be operated within a narrow frequency range to optimize its power consumption—if the device is driven at the resonant frequency of the spring, it will consume less power to produce a vibration of equal magnitude”
Repeating the basic principle again. Get rid of this and get right to the next sentence about how you can use a fixed frequency/varying frequency.
Using github to search like this reminds me of how a CS professor of mine would show the "best commit messages of the year" (homework was submitted via git) by looking for various patterns like all caps, all symbols, etc.
"The Strange Log" is a Twitter account that tweets bug fix comments from games' release notes. Without context, the comments can be rather mysterious or surreal:
Spouses less likely to run away into the dark abyss.
Bald inmate digging grows hair.
Player can die from lava while praying successfully.
Colonists will no longer stare each other to death.
Trash monsters will now have a chance to drop the intended cat ear colors.
Suicide animation speeds up search for apples, berries.
Fix trees not going to their burnt state when they go to sleep while on fire.
Potions are tasting much better now, especially the harmful ones.
The Pinking Shears stir from their slumber, awakened by what may seem, to those innocent in the ways of The Shears, a triviality, a nothing-of-consequence. But there are consequences indeed for recklessly trailing your whitespace. Naturally, they a dire!
One, two! One, two! And through and through
The Pinking Shears went snicker-snack!
They plucked your tail and with your space
They went sniksnuking back.
Let me tell you, that can be uncomfortable, so always pre-sniksnuk your trailing whites. May The Shears be with you.
I definitely aim to remove things like that, but I tend to sneak it in with something else (partly because the fix likely came as soon as I used an editor properly configured to strip it).
I'm not sure if that's a 'bad' practice or just not the purest. But I don't think removing trailing comment space is bad in itself. As above, it probably didn't take any time at all; done automatically by a well-configured editor.
What really struck me about this is that for me, personally, it would be very difficult to use both of the skill sets demonstrated here at the same time: coding and writing prose.
In case anyone looks at that and thinks it's cute or clever or fun... it's not. People will end up hating you for doing that. Okay, maybe hate is too strong, but it will certainly engender some strong negative feelings in anyone who has to try to figure out what you did (and when and why you did it).
A common objection from new developers is that "commit messages are hard and they slow me down", so if that's how you feel (for example, you're starting a fresh project): go crazy with your commits and don't let them slow you down. But then rebase, squash, and edit the commits before sharing them.
If a developer consistently pushes commits like this, they should be guided by their team lead to understand their importance. But if over time they refused to improve them, in many cases that would eventually be fireable. Commits are the technical paper trail: whether used when diagnosing issues, merging, compiling release notes, or whatever. Making the messages clear is extremely important.
This is pretty simple to do outside of die-hard "continuous integration" shops -- most of the time I can just do
git rebase -i HEAD~4
(where '4' is the number of little dumb commits I made) and squash them all into the first commit.
But if I made a few commits, then pulled in someone's changes, then made a few more... well... http://xkcd.com/1597/
Hahaha, I went through the masters of comp sci program there. Those commits mentioning Borja cracked me up, and I swear "i love the smell of segfaults in the morning" was written on the wall in the big lecture room in the physical sciences building. Gives me flashbacks - that program was brutal (though really good).
Just looking at this one course and the projects... This is night and day harder than anything I had to do in my CS program. We just dicked around in Java for most of it, no C, and definitely no low level socket programming or reproducing an RFC.
I had (1992, man.ac.uk) VDM, Pascal, SML, Prolog, midi-port communication in 68000 assembly, Pascal-with-embedded-Oracle, Tarski's World, etc., and not a single damned thing from that course has been useful since.
Yeah I came in thinking it would be easy after crushing the programming pre-req tests. Was in for a complete surprise - they don't mess around at UChicago.
In the masters program you can somewhat build your own degree after taking their core classes, so you can at least study what you're really interested in (or avoid the hard stuff like a lot of people did). Most of the profs had real industry experience too. A C++ class for example was taught by a guy who sold his company, now is a research fellow at a huge lab, and sits on the standards board. We got to bounce questions off Bjarne Stroustrup. Was pretty cool.
And youR* reply is about as useful as the whole thread, the reporting of other peoples laziness of committing with proper descriptions of their own code. What a surprise, people are lazy and it bites you in the ass in the long run wowiwow, what a surprise...
Perhaps if this type of post didn't come by every X time, it wouldn't annoy me so much.
I write software for desktop CNC machines, and am a maker myself who periodically sells his work. I constantly am thinking about what it means to be 'hand-made'. The machines I write software for can only make one thing at a time, it isn't large scale manufacturing. The designs are hand-crafted, I suppose, but they are of course made digitally. The machine is controlled by the computer, so the process of carving doesn't involve any manual skill. However a piece is rarely 'finished' the moment it comes off the machine. An added level of complexity, for myself at least, is that I am writing the software that controls the machine. Does that make the things my machine creates any 'more hand-crafted'? I like to think it does, but I'm not sure!
I'd say the "source code" for your designs is hand-crafted, but the material coming off the CNC machine is not. It may not be mass manufacturing, but if additional copies are essentially a button-push away, I'd say that it wasn't hand crafted. Now if the setup time on the CNC machine took longer than making it on a manual mill/lathe, then we might have some grey area. BTW, what are you using for your "desktop CNC" machine? Do you have any recommendations? And what materials are you machining? Steel? Brass? Aluminum? Plastics?
I think mavdi really meant "diagnosed sooner". Or perhaps cancer deaths could be prevented? Either way, just google "cancer blood in urine" or stool and you get the idea.
The single most important book I think I've ever read. I've never read something that I kept coming back to year after year, reading a little farther into it every time. If I was stranded on a desert island with only one book, I'd bring this one. It would keep me busy for more than long enough.
According to him that's what the books core idea seems to boil down to, but I think I'd bring the book with me because of all the other things as well: "fugues and canons, logic and truth, geometry, recursion, syntactic structures, the nature of meaning, zen buddhism, paradoxes, brain and mind, reductionism and holism, ant colonies, concepts and mental representations, translation, computers and creativity, consciousness and free will, sometimes even art and music of all things!" -preface to the twentieth anniversary edition
We are hiring software engineers and designers. We make our own desktop CNC machines and write software for the whole stack, from machine firmware all the way through to the browser-based design app, Easel. Our main focus right now is (1) making new ways of designing in 3D and (2) making the feedback loop between design, simulation and carving faster. That means lots of unique technical and UI/UX challenges.
If you are interested in design interfaces, how/why people learn to make, computational geometry, or if getting involved in educating the next generation of makers, we are looking to talk to you.
https://boards.greenhouse.io/inventables/jobs/97588#.WBeb7uE...