Tuesday, September 24, 2013
Is it a job?
Monday, September 23, 2013
Cc2541 ti bluetooth mcu
This may work for a replacement to my arduino/Bluetooth combo for music glove, need to install eagle to view for size http://t.co/nzGrj1LBKa
And may need to adjust circuit, ideally I would like coin battery usage
Pressure Sensor
Don't have time to watch this right now but may be a solution for my fingertip buttons http://m.instructables.com/id/eTextiles-How-to-Make-a-Pressure-Sensor/
Wednesday, September 18, 2013
My thoughts on Projects and Learning
While I was mentoring one of my good buddies, we talked about projects and the like a lot. It was interesting, and I came to the conclusion that there are 2 primary types of learning when you're out there on your own. There is learning for the sake of learning, and learning to accomplish a goal (which is not learning in this case). I'll talk about each a little and what I think about them.
School Learning
Learning for the sake of learning is going through an entire API just to read up on it. Learning all the details of a language just to know it. One of the benefits of doing this is that you end up having a deeper toolbox to give you more understanding of the underlying structure. In some cases this learning may actually give you ideas because you didn't even know that particular aspect of an API or language worked that way or existed. Often times it simply allows you to recognize patterns of problems as well, if memorization is involved. The downside is that it's slow, if you spend the time to read every little bit of an API, or language, by the time you are ready to use the language (or API) they may be out dated.
Real Life Learnin
When you start a job in the real world, you don't just take the tools you learned in school and use them and nothing else. You start picking up new things constantly, and usually (unless you work at a really cush job) you won't be given the time to spend reading every bit. What you find is that you define your problem, break it into pieces, determine what pieces you know and which you don't. From there you research enough about each piece to complete it. The benefits of this approach is the quick feedback loop. You discover quickly what works what doesn't, what's easy what isn't. You also can start hitting a wider variety of items in your toolbox. You don't get the depth of school learning, but unless you are writing a very complex piece of software, or debugging, a cursory understanding is sufficient to complete the task usually.
When you set out to learn what approach do you find most useful? Do you use one or the other? Maybe a hybrid approach?
Why I decided to become an Engineer, or Why do I do what I do
When I was going to school, I would ask other students occasionally why they chose Engineering. Often times the answer was "My father or mother is an engineer, so that's why I decided to be an engineer". Occasionally, I would get a "I liked to take things apart so I figured ...>Engineer". Rarely I would get a "I don't know, someone said I should be".
While there is no right or wrong answer, doing it just because someone told you to just doesn't seem quite right. Doing it because you look up to someone is a pretty cool way to get into it, although without that curious nature I think you're pretty limited. I'm sure there are tons of awesome engineers who are engineers just because someone they looked up to is an engineer. And I'm sure people look up to them even now (which is pretty cool). If I were to pick a reason someone should become an Engineer I would have to go with the second choice personally. If you have a curious nature and like to look at how things work, thats headed in the right direction for what I think makes a Rockstar Engineer.
But this post is about why I decided to become an engineer, so I'll tell you (by the way, if you are an engineer, or well anything, tell me about what made you decide that career choice!). Way back when, I moved to Albuquerque to work on Flight Simulators for Lockheed Martin, it was a pretty cool job, but I was hired as a Tech, and thus was supposed to do "tech" stuff. This meant only hardware, even if I looked at the software and found a problem I wasn't allowed to fix it. A "degreed" engineer was supposed to fix it. I really loved how you could control something physical with software (re: I/O and robots, and lots of embedded stuff). I decided going back to school was the only way I would get to play with that stuff professionally. Back I went.
A number of years later (working full time and occasional semesters of full time) I managed to get my Computer Engineering degree from UNM. Just having that piece of paper opens a lot more doors I think. However, if you don't have a curious nature and want to learn more and more. You'll start running into more and more doors closing as time goes on. Just having a piece of paper might get you to an open door and talking to someone (especially in the early days of your degree), but if you're not constantly bettering yourself, and pushing yourself to learn more, you'll find you're falling behind.
Why do you do what you do?
Monday, September 16, 2013
Class Inheritance Problems In Python
I tried to call a function on a child, that calls the parent and uses the self attribute. It wasn't having it.
I got the error
AttributeError: Class Instance has no Attribute '
After some searching I came across this post, it was a little confusing but I think I finally got it.
http://stackoverflow.com/questions/16528171/attributeerror-child-object-has-no-attribute-name
Here is an example of the result in action:
*Notice I had to do Animal.__init__(self) for the function to work. It took me quite a while to figure this one out.
Tuesday, September 10, 2013
School, Learning, And What to do with it.
I became a little more enlightened. You see, I don't need to use almost anything I learned in school, except for some of the solid basics, you know, reading, writing, arithmetic. Its when you start trying to solve harder problems that people don't ask you to solve, that you discover that using those tools makes things easier.
I'll give you an example.
I was working on testing some code, it's pretty complicated, and it requires lots of inputs, it outputs 3 values. Now to figure out how to get a particular output can get kinda tricky. So analyzing the function, if you can reduce the number of inputs that change the particular output that will make your job easier.
One way of solving this problem is attempting to plot the inputs, and the outputs and look for commonalities. This was my first attempt at solving this problem. After speaking with a fellow colleague (You know who you are, if you want to be credited I'd be happy to link to you), he suggested that I could write a search algorithm. You see, I had completely forgotten about finding "maximum" and "minimum" values, I even think I heard about it in my Machine Learning class, but unless you are actively searching out these problems it's easy to forget that there are solutions you've already learned about.
Even better my colleague suggested that that particular line of code might be to prevent the variable from causing out of bounds (WITHOUT EVEN LOOKING AT THE CODE, THAT'S HOW GOOD HE IS). How did he know this? He listened to the signals. I mentioned things like Cosine and Sine were being used in the function. He knew at a high level what KIND of calculations were going on. So he made the guess that it could be protecting. He was right!
So all I can tell you is to keep actively seeking out those problems and using those tools we were taught. I was wrong. I can admit it.
On Converting Ada to Python Pt 1
I.E.
Ada:
function Convert_to_Something(This : in Dog) return Animal is
begin
return This.Animal
end Convert_to_Something
Python
(in class definition)
class Dog:
def Convert_To_Something(self):
return self.Animal
How they're called:
Ada:
Convert_to_Something(This
Python