"IDE" entries
Embracing Java for the Internet of Things
Technology executive and enthusiast Mike Milinkovich on Java's role in shaping future enterprise development.
Hardware and software are coming together in new and exciting ways. To get a better sense of this excitement, one need look no further than the nascent explosion of connected devices and technologies. But how do we best cater development for these emerging paradigms, and how do more mature languages, like Java, fit into the equation?
I spoke with Mike Milinkovich, Executive Director at the Eclipse Foundation. Mike and his team are currently leading the charge to promote open source IoT protocols, runtimes, frameworks, and SDKs across a variety of languages, including Java. Eclipse’s IoT stack for Java is already being utilized by such companies as Philips, Samsung, and eQ-3. Here, he talks about Java’s unique standing in this emerging marketplace, and the impact of the open source community on IoT development.
Debugging for beginners
Nobody's perfect, and neither is your code, but that's OK
I discussed one thing that developers hate last time around — commenting — so I thought I’d follow up with another big source of developer frustration: Debugging.
Bugs happen. Every developer in the history of programming has had to debug, even the legendary ones who write code with butterflies. Becoming a skilled programmer doesn’t mean never making errors, it means becoming better at finding and fixing errors. When you’re starting out, your programs will likely be small enough that you may be able to figure out the problem by taking a closer look at your code, paying attention to the syntax, and tracing the execution process in your head. Once you get beyond that initial stage, though, you’ll need some help to find the bugs.
The art of commenting
Is commenting your code a waste of time, or programmer gold?
Ask any developer what programming task they enjoy least, and odds are you’ll hear “documentation” as an answer. After all, you came here to write code, didn’t you? Who wants to write boring text about the code? In fact, documentation is the grease that keeps the development process moving — good documentation benefits your co-workers, the users, and maybe even you. And the most basic form of documentation is the comments in your program itself.
To IDE or Not to IDE?
Choosing the right tool for the beginning programmer
You’ve picked the language you want to learn, and you’ve learned more about the various language paradigms. You want to get started writing some actual code—but what tool do you use? With almost all languages, you can start writing code in any old text editor available to you, and that’s what programmers used to do, decades ago. Any good engineer, though, will find tools to make his or her job easier, and that’s where the Integrated Development Environment (IDE) comes into play. So now you need to learn how to use a tool before you can learn the language? Not necessarily. Although many programmers consider “should I use an IDE?” to be a question with an obvious answer, they don’t necessarily agree on what that answer is.
Is Text the Programmer’s Silver Bullet?
The command line and text editors retain their charm
Will programming ever depart the land of text?
I loved this article on the divides between user and programmer cultures, but sharing it brought responses on the values of programmer culture. Every time I wonder publicly about programming interfaces, or worse, suggest that graphical interfaces might play a role, I provoke a small army of people who think text is a key strength of programming. Though they sometimes wander into IDEs, text editors and especially the command line are their critical tools.
Bruce Maxwell, Professor of Computer Science at Colby College, described the power that text provides:
I’ve watched student after student come to the same conclusion that editing the text file is faster and easier and more precise. I’m not imposing my 1980’s C preferences on them; they are discovering this anew for themselves.
It comes down to this: you can create nice, general graphics tools that will let you do a certain set of tasks in a certain design space. But as soon as you have a specific idea or concept or need that falls outside of those tasks or the design space, or you want more detailed control, you fall back to the most general tool of all: a text editor and a programming language.
He’s right.
I was amazed, the first few times I attended OSCON, that the deeply-felt arguments at lunch weren’t about programming languages or principles, but about editors (Vim vs. Emacs) and about shells. The divisions among different ways to reach your text crossed language boundaries, and even varied within organizations. (Well, at least those that hadn’t standardized on IDEs.)