A common situation for us (people in the programming/computing/processing world) is that we don’t always work with the same tools as some of our non-tech peers.
Case in point, I received a big bunch of files in XLS/XLSX format, very big files, LibreOffice has trouble working with them. Since I want to perform quick processing on that data, and I already have scripts that process similar data in CSV, the simplest path is to transform those files to plain, ugly, useful CSV files.
Then again, there are 100 files, and I don’t feel like dancing around each one: opening, clicking save as, selecting CSV, telling LibreOffice that this is a semicolon separated CSV file … etc etc.
Unit testing is something that lots of developers are used to, and in environments like Python or Java can be even bundled in some awesome libraries. Easy to use, easy to implement, great results.
Then it comes C Embedded: The environment is different, even the people is different!!. Praising the benefits of unit testing is not that easy sometimes, even writing the unit test functions is not as straigtforward.
In this post, I’ll talk about Unity, a small unit test library for C.
See how we test
A simple post on how to configure a Logitech Trackman Marble on GNU/Linux. This post is tested on Ubuntu but since this is Xorg configuration it should be usable almost everywhere.
I discovered XCircuit when looking for an easy and quick way to generate a schematic.
Since I am not going to simulate it, it would be enough to have a vector design program like Inkscape, but it’s never too late to learn a tool that may prove useful in the future.
There are other bigger, better, stronger EDA tools: Geda, KiCAD, EagleCAD… but I settled for something designed for publications.
(…)program for drawing publishable-quality electrical circuit schematic diagrams and related figures(…)
— XCircuit website
In this post you’ll find a quick overview of XCircuit, and how to create a module with it.
Ranting is not my favorite way to express, I’m more like a constructive guy. But also, the blog is a reflection of what I’m doing right now. And for the title of the post you can guess I’m not doing a lot of GIS.
Lately I’ve been spending my time reading some questionable code, which made me think about the habits of programming. There’s no exact science here, but it is true that bad handled code can explode really fast creating a series of problems.
- Maintenance hells.
- A bug fixed, uncovers another bug.
- Hard to get somebody up to speed.
- Lots of snorting (iup that’s me).
- Clear increase of gray hair (iup, that’s me).
I started drafting a post about this topic. Then, it exploded in size. So I decided to split it in digestible bits of enjoyment.
The original title was: The Code Apocalypse but I settled for something milder because… that’s my style :-D.
Filed under code, tips, TSP
This one is going to be short, it is something that would fit better under commandlinefu, tips and tricks!
What do we want to do?
Look for al the cpp files under a directory and modify all the text with foo to bar.
How to do it?
First we find all the cpp files under the current directory
find . -name "*.cpp" -print
And a possible command to replace from a file is using sed.
sed -i 's/foo/bar/g'
We just have to connect those two together to replace in all the files with a name ending in .cpp, that’s what pipes are for.
find . -name "*.cpp" -print | xargs sed -i 's/foo/bar/g'