How much automated/pre-written code will you tolerate in your projects?

For me it depends entirely on the source. I don’t mind using open libraries and that sort of thing, of course. And I’ve also seen programming languages like Vala, which translate into C code and run that; that’s a form of automation, of course, and it can be done quite well. In fact high-level languages in general are basically all ways to automate writing machine language.

Yet there’s a point when it becomes annoying and difficult to work with. You know where I stand on Visual Studio. I’m not that fond of bulky IDEs in general, though. gedit is my bestest buddy, nano if I’m not using the GUI. They’re simple and minimal and there’s no giant learning curve.

Of course this isn’t confined to programming proper. We’ve all heard (or experienced) the horror stories surrounding Adobe Dreamweaver, the HTML-generating application. That’s a glaring example of automated code gone horribly Frankenstein’s-monster wrong. I notice that a lot of “build your own web site” applications tend towards that fate–with the notable exception of WordPress, which I really like. (Obviously.) WP is open-source, though. It’s special.

I’ve found that anything that wants to write code based on user input from a GUI has a big hurdle to overcome. GUI input can be really nebulous, and comparing it to code is kind of apples and oranges. Reversing changes made in this manner can get even messier, but naturally the user will want to do that too.

I think my complaint is that the automation can be executed very clumsily, and such an execution can be excused and have a market because people are so afraid of code. Even novice programmers are pretty afraid of code. It looks intimidating at first glance! Even when I pull up someone’s source for the first time and try to figure out what it does, it can be overwhelming and confusing, and I’m used to seeing code by now. So people who don’t know any better will look at a GUI, or a similar graphical display of what the code’s supposed to be doing (this seems to be the appeal of flowcharts, UML, and perhaps even pseudocode to a degree), might be seen as comforting. Like a visual map. Just beware of drunk cartographers.

I think the reason we have that problem as much as we do (people wanting visual maps, not inebriated mapmakers) is that we don’t know how to teach programming. ESR’s advice in “How to Learn Hacking” is to start off with working on programs that are just a hundred lines, then a few hundred, then a few more hundred, then a thousand and then three thousand and so on. Although I don’t remember if he mentioned it and I don’t feel like digging it up at 4AM, which is when I’m writing this, this is so that you can learn to hold programs in your head. Uh… there was a Paul Graham essay about that that I liked, too. I’ll throw some links in this thing later maybe.

If you don’t learn to hold programs in your head–their structure, also known as their this-relies-on-this-which-uses-this-to-do-this–then the desire for a visual representation is a lot greater.

Again, visual representations CAN be useful. Loading a program into your head takes time, a lot of time, and that overhead is greater the longer/more complex the program is. So if you make a UML diagram as notes and that helps you reduce the time it takes to page in a program, great! If you come up with a system of monkey-scrawl notation that only you can understand and that helps you reduce the time it takes to page in your program, equally great! Because the same thing won’t work for everyone. And half the usefulness of such diagrams is in having made them and semi-consciously remembering making them. Let your buddies, coworkers, cofounders make their own; using yours wouldn’t be as effective.

Personally, I like comments in code. If someone who’d studied the programming language for six months couldn’t look at a chunk (a few lines) of code and tell in under 10 seconds what it does, it should have a comment stuck on it. Even more so if it’s convoluted and contextual. I also believe in the art of making these comments fit on only one or two lines, though. It also helps when you’ve been banging on your code at unholy hours and forgot in the morning what you did.

I also like using monkey-scrawl notation. Less as intentional reference, usually; more as paging out thoughts and ideas in order to make sense of them. But they can serve the purpose of going back and understanding what you were thinking earlier as well.

Anyway, it’s 4AM and this stream-of-half-consciousness essay needs to end. Tell me what you think in the comments, and good night.

 

Kivy + inexperience = confusion

I’ve been trying to hack on my app all day, but I’m still at the slow end of the learning curve and although I don’t easily get frustrated with tech, I am getting brain-tired. And after the Internet yielded iffy tutorials, I broke down and looked for a book. I didn’t actually think there’d be one yet–Kivy is only a few years old AFAIK–but there were actually two (maybe three? four if you count the one that was in Japanese). A low number, yeah, but for a young and kind of obscure piece of tech, I was surprised.

One of the books I found was made by O’Reilly–naturally, I went for that one. I’ve had really good experiences with their Head First series–my first tech textbook was a HF book–and, besides, they’re just… classic. If you don’t know, O’Reilly is kind of a gold standard in hacking textbooks; a name brand as recognizable to nearly anyone with programming experience as “Kleenex” is to nearly anyone living in a first-world country.

I decided I was too hungry for instant gratification to wait a week or more for standard shipping rates, too cheap to want to buy the Prime book which was more expensive, and had too little space on my bookshelf for another programming textbook, so I ordered it for my Kindle instead. The Head First books don’t really translate well to ebook form, because of all their pictures and diagrams and double-page spreads. (Tried that with Head First Java. Acquired headache.) I don’t think the ordinary O’Reilly books are quite so visual, though. I guess I’ll find out. Either way, I really need to clear out space on my bookshelves–I have an entire deep desk drawer full of textbooks from classes, and four more of my own just laying around my room. I probably have enough technical literature to crush a small sheep if it was dropped.

This is probably why my older brother got me my Kindle.

I’ve been working for about… eight hours? today, just stopping for food and to shower. I feel like I could keep going, but this is a good stopping point for the night and I’m just gonna leave the hacking here for now and let my brain recover a little.

That’s all for now.

My first phone app

I’m really wishing for a more experienced hacker to help me with this. Or at least another smart 18-year-old. (Hey, Steven, you want in on this?) I’m having issues figuring out where to start, and this platform is so foreign that I’m not sure how to do things like work with files. On a normal computer? No problem. On a phone, working with the Android OS? Uh… not sure. But I’ll figure it out.

I’m working on a phone app that will store all those little bits of paper people shove in their wallets. No, not money–I’m talking about business cards, receipts, scribbled addresses on the backs of envelopes, notes to self, maybe checks (for those people who have the banks that support sending in a picture–this would have to be password protected), coupons downloaded off the Internet… stuff like that. And all the metadata you’d need, like when you added that business card to your collection, whose name is on it, what business it describes, etc.

I’m also thinking that maybe it should use a light compression algorithm–I mean, if it’s gonna store all this stuff locally, which I would like it to, because it’s convenient that way and I don’t want to pay for a server to do it for me. Or I should just make sure it’s not storing huge, high-quality images like the camera likes to do; they should at least be resized to like 250×400 pixels instead of 1250×2000 or whatever the camera does automatically. Maybe if it catches on, I can get some VCs to back me and I’ll buy a server and allow people to pay for cloud space.

I’m using Kivy to develop this, because it’ll let me program in Python rather than Java, and it has a lot of other neat features I like. (Yeah, I can see where Lisp’s macros might be useful here, but I’m going to stick to OO stuff for now. Especially if I want to actually find someone who’ll work with me.)

I think people need this app! I’m going to sneakily develop a dedicated user base of everyone I know before I start really touting it and drawing the attention of companies that might copy me. It’s hard to fight the force of users who’ve already learned to use something that subsequently made their life easier.

My dad definitely needs it Not just his wallet but also his car is always full of little bits of paper, because he runs a stump removal service.

I want to keep the design and interface as simple as possible. I can see the possibility of something like this turning from lean and neat and space-efficient to bloated and confusing.

I’m not sure whether I want to keep this to myself and maybe a friend and develop/release it by myself/ourselves, or if I’ll throw it to open source. I don’t think it’s really meaty enough to benefit much from open source… it’s such a little, simple idea.

I have no money for this project, I’m the only developer, and my prospective clients are myself and my friends/family/teachers. The communication overhead is an advantage (i.e., the lack of one), at least. And I’m also not working under a deadline, although I’d like to have something running and usable for people to play with when I go to TechWeek in September. I bet I can get a good chunk of this thing done by then, even with the learning curve I’ll go through.

Anyway. Time to start really hacking, I think I’ve got a good basic design down on paper.

Oh! One more thing. I’ve got a name for it now! It’s called tinypapers. It took me a while to come up with that because the purpose of this thing has changed drastically since I’ve been mentally designing it for a few weeks.

How I Learned Linux

[Update: A bunch of you are here because Eric S. Raymond is awesome and nice. Thanks, ESR!]

And, by extension, how you can.

I’ll start this off with a disclaimer. I am not a Linux expert by any means–in fact, I’m not even fluent, and don’t use it as my main operating system. However, if I sit down in front of a Linux computer to do some work, I’m perfectly comfortable with using it. I can use the command line comfortably, I know what repositories are for and not to download just whatever interesting-looking tarball off the Internet (unless I’m doing so to tinker with it), I can do a tiny bit of shell scripting, and I can even compile or interpret my own programs (written in less annoying languages) via the command line.

Most people are not there. It took me a long time to get there; I remember being interested in Linux long before I figured out even how to learn how to use it.

The boost that let me get into the Linux world was discovering virtual machines, which are great for letting you play with different distros, screw things up, delete everything if you want/need to, start over–all sort of nonsense. It’s worth noting that Linux systems won’t be as reliable on a VM because of funky stuff with virtual hardware and guest additions and that kind of thing. The tutorial I wrote earlier can help with that. (If you’re used to Windows, you won’t notice anything strange about their reliability.)

You don’t need to take a formal class on Linux. In fact, if you really want to learn Linux, taking a class will feel painfully slow for you and will probably try to teach you silly stuff like how to get X Windows [*] to run on a network, which will be boring and frustrating. You can learn much of what you would in a Linux class by tinkering–although, if you’re focused on computer networking rather than programming, you might like taking a class.

On whether it’s right to write intro posts like this

Hackerdom seems to contain a large contingent which considers that anyone who can’t find the information in the rest of this post for themselves isn’t worth helping, because they won’t have the right spirit or work ethic. I disagree. It’s entirely possible to not even know what to type into Google in order to start solving your problem, and this doesn’t necessarily imply anything about the person who is confused. Whether they’ll admit it or not, many hackers will have been similarly helped by being around other hackers who at least know what program their juniors are looking for but don’t know exists. This is what Linux User Groups are for–but, again, most people don’t know those exist, either.

I can understand not wanting to spoon-feed people all the way, and someone with the true hacker spirit wouldn’t want to be spoon-fed anyway because it’s too much fun to do your own research, since you run into lots of other interesting knowledge along the way. But I don’t consider it a detriment to the Linux world to give people a boost in, so here we go: how to get comfortable with Linux.

No, I’m not going to describe what everything does. This post would become ridiculously long and that IS something you can Google for yourself. I will, however, provide you with good links and descriptions where they’re necessary. 

—

1. Set up your first virtual machine (VM).

i. Download VirtualBox (opens in new tab)

ii. Download a torrent client–a reader suggested deluge or transmission; I haven’t used them myself. I use uTorrent, but as I don’t know much about P2P systems, I pretty much picked the first one I found. As our commenter pointed out, uTorrent has certain questionable downsides. Perhaps when I have time, I’ll do some research about the different torrent clients and do a post about it.

Also, learn how to set it up. If stuff downloads, but only uploads at a painful snail’s pace, you probably have it set up wrong (although you might just have a less popular distro).

iii. Torrent at least one Linux .iso file. If given the option, choose 32-bit.

Distros (distributions) you might want to play with include Xubuntu (which is pretty easy to use and has a decent interface), Debian with GNOME (which is my favorite), Fedora (which is a little different! but maybe you’ll like it), and Mint (which, depending on which one you get, may be based off of either Ubuntu or Debian–it’s kind of a nice middle ground between them and very popular). I suggest making VMs of any distro you’re interested in, and playing with them, rather than relying on other people’s opinions about which you should use. Those posts can be fun to read, but not very helpful in the long run.

Distros you should save for a point when you know what you’re doing better and want to explore other things Linux can do include, but are not limited to, Puppy Linux and Kali Linux. Puppy is meant for running on tiny systems and can be run on computers which don’t even have a hard drive (it can run on just RAM), and Kali is meant for digital security testing. Please don’t do anything stupid with Kali.

iv. Set up your VM.

There are a lot of how-tos on this subject, including my own, which I just updated; I really suggest that you get into the habit now of checking more than one to see how they’re different and how one might be better than the other. My own included a few weird voodoo/cargo-cult programming things that were in there because they’d made something work for arcane reasons when really it was something else that was wrong–which is why it just got updated, and why you should always look at more than one tutorial. Keep the links of good tutorials; you’ll meet other newbies who need them.

2. Learn the command line.

There are numerous excellent tutorials on this. I don’t need or want to rewrite them, but I will link to them.

Zed A. Shaw’s tutorial at the end of Learn Python the Hard Way. Start with this one. Keep the link; you can learn Python at that web site, the tutorials are really good. Don’t be dissuaded by the name, it’s easier than learning from the dispassionate bureaucrats writing Microsoft programming manuals any day.

How-To Geek (Will teach you how to install things, very important–although if you’re using Fedora or a derivative, you can’t use apt-get. Just replace “apt-get” with “yum” in any of the commands mentioned and you should be fine.)

If you’re still confused about apt-get, look here for Ubuntu’s how-to.

LinuxCommand.org — I don’t remember reading this all the way through, but I had it bookmarked, so probably it answered some question or other. Come back to it if you have questions.

3. Don’t break your system (unintentionally).

Sometimes you intentionally pound on stuff to see what breaks it. However, if something breaks and you have no idea what you did, that’s a glaring neon sign that you haven’t learned enough. It helps to know what kind of stuff will break your system and why before you get to that point, though.

Here’s a link I found with good advice. It says Debian, but the points it makes are not Debian-specific.

Don’t Break Debian

4. Know where to go for help.

Your first resource when you don’t know how something works should be this really helpful command that you NEED to know. It’s called “man”. No, there isn’t a “woman” command. “man” is short for “manual.”

Typing “man ls” into the Terminal will show you everything you could ever want to know about the ls command, including different formatting options like -a and -l. The utility of those flags may not seem like much, until you write a shell script that needs to use ls and have the output in a reliable format, so man pages can be your best friend.

Man pages can also be found on the Internet.

Google is your other best friend. Learn how to use it, please; it’ll save everyone’s time, including yours, in the long run.

However, if you’ve spent more than 30 minutes to an hour (depending on the complexity/obscurity of your problem) trying to find answers, it’s probably time to go to a human. Preferably, one who can program.

Your distro will have its own forum. If you’re trying out different distros, make sure you go to the right forum for the distro that has the problem, even if the bug isn’t distro-specific.

There are also more general Linux forums, like this one which even has a newbie section.

5. Learn the secret handshake.

I was going to make a joke about this to finish off the article. Then I realized there actually is kind of a secret handshake, if you want to be a hacker and not just become competent with Linux. Consider this optional but fun; it may help you stick with Linux instead of giving up, so visit these links if you get bored.

The Jargon File

How to Become a Hacker

How to Learn Hacking

—

This collection of links should set you in good stead to becoming competent with Linux. If, given this boost, you can’t get any further or find anything interesting to do with what you’ve learned… well, that’s the point where we’d be spoon-feeding you. But I think it’d be hard to get through all this without sort of learning the attitude and skills you’d need to keep going, if you wanted. If you weren’t cut out for this sort of hobby, you probably wouldn’t have had the persistence or interest to make it through–you would have given up halfway through this post.

Good luck, and happy hacking!

*X Windows is an older remote access program, and a window system. It used to be a reasonably good program, I’ve heard, but it’s not a good option now. It would allow you to virtualize one computer’s GUI on another computer. But there are inherent security risks in programs that transfer GUIs over a network–at least, so far. If there were a startup that wanted to improve that, I bet there’s a huge market for a secure remote access system.

Our teacher didn’t like it–she’s a firm believer in using SSH and the command line for this sort of thing, and I agree until someone comes up with a better solution–and I don’t think the textbook writer liked it either because he put it at the very end of the chapter, after all the other options.

 

SSH is faster anyway.