My wife and I bought our first house at the beginning of 2017. In this house I have finally created my own little demo studio.
I am currently working on a project where I need to parse Open Xml files comming from the Office Suite. As you may already know this involves opening what is essentially a zip file full of xml files.
I recently had to debug an error where stuff that should have been returned through a server to server call did not work correctly. Both servers - in development mode at least - was on my local machine. But since I had to hack either an external dependency or the sending server to find out what was actually being sent between the servers - I realized this was a great time to utilize the tcpdump tool.
For some time I have had the idea that when I have written enough lowlevel mini-tutorials about how to do the most basic things in every language I have ever worked with on Polyglot Bits I would begin doing small projects.
Csharp was probably the first compiled language I really loved. When the first version of .net came out I wrote a small CMS using C# and the new runtime. (A big step up from old school asp)
Reading a file in lua is pretty straight forward.
Lua is among the programming languages - that I write about here - I have used the least.
My son (Toke, 7 years old) and I have long talked about making our own computer game.
Reading a file in C++ is almost identical to how it’s done C.
To create a plugin system in C++ you need three things.
In C++ there are no built-in ways to handle json. However there are many open source libraries to help you.
Java is - off course you might joke - rather verbose when it comes to reading files. However most of the verbosity has to do with importing the functionality from the standard library.
The go standard library has all you json needs covered. The JSON package has methods for both encoding and decoding to/from JSON.
Parsing JSON in elixir requires an external tool - and you’ll need to define the types the data needs to be parsed into.
NOTICE: This may be obsolete. I stopped using HyperTerm again! (Too many things failed). The project has been renamed (to “Hyper”). And the special handling for danish keyboards seems to have been fixed. All in all - you may learn a bit about how to create keyboard shortcuts - but the specifics are probably unusable now.
I love working to some kind of (controlable) background noise. Something I can mostly ignore while working, but that I can focus on when loosing my train of thought. Mostly I use music but lately I have found that (some) movies helps me as well.
When your C++ projects grow a little, you may find yourself needing to log the state of objects. There are two ways of doing this (assuming that you’ll want to log the data the same way each time).
In haskell there are two ways to read the stdin stream. Which one to use depends on what you’re trying to accomplish I guess.
Reading from stdin in C++ is surprisingly concise. Only 12 lines of code (including includes and empty lines).
Writing to a file in c is surprisingly simple. Most of the steps in c can be found in most other languages as well. In c you open a file, write to it and close it again. In most languages you either do the same exact steps - or have a higher level construct that does the same thing for you - but every language will ultimately make the same sys-calls that the c languages shows us directly.
In go you will sometimes write more code than you are used to in e.g. most higher level languages (think php, ruby, python) - but will have a lot more control over how it is done.
Just as with reading program arguments - lisp looks a bit weird when reading from the stdin stream. That is until you get the hang of it.
Lisp is a completely different way of looking at programming than e.g. ruby is. Where in Ruby everything is an object - in lisp everything is a list. Which makes sense, since lisp is an acronym for LISt Processing.
In Ruby you parse json by first including the json library (either the one provided with the language - or any one of the gems that provide the same functionality)
Reading from stdin in ruby is as easy as calling STDIN.read
In c you are as close to the metal - or at least as close to the os - as possible in a high-level language. This shows in the verbose code you need to make a simple tcp server which echos messages back to the client. Furthermore this implementation of the server will only ever accept one client - and when that client disconnects, the program exits.
In Ruby there is no built-in support for parsing and writing xml. There are however a couple of gems (packages) that allow you to do exactly this. If you are working in Rails - you have this for “free” with ActiveSupport (which you could also just require as a standalone package). This gives you a to_xml on a hash which is dead easy to use. There is also the xmlsimple gem which is a port of the same library from perl.
IISResetMe has made another Program Arguments script. This time in perl. Reading perl has always been weird for me. I have never used perl for much myself - but I have written a lot of php and a lot of ruby - and it shows where they have borrowed many of their ideas.
Once again php shows how it is an easy language for beginners. In PHP you don’t have to think about much when you want to parse json. Json parsing and encoding has been part of the core php language for several version now - and before that as an extension with the exact same methods.
Reading a whole file is as easy as one function call in PHP. (Especially good if you want to read a small file, and want all the data in memory anyway).
Reading from stdin in go is as easy as reading from os.Stdin - the ioutil.ReadAll method reads all bytes into a buffer and allows you to handle the input once it is read. If you need to stream data to a go program you need to read os.Stdin in some buffered way - since ioutil.ReadAll blocks until it receives a EOF.
In ruby you read a file in two steps. First open the file, and then iterate over the contents. (In this instance we loop over the contents of a text file so the built-in each_line is what we want.)
Reading files in C is very easy. First you need the stdio.h header file included, then you need a pointer of type FILE, and you call fopen on a filename (setting a flag to tell what access you want - here we just want read access).
This is the one programming language to date where I have had the hardest time doing the little hello world program that prints a hello line per input argument.
Rust reminds me of C in many ways. The program arguments include the program name at the first index, but unlike C you have to make a function call to get the options.
let args: Vec<_> = env::args().collect();
There seems to be two schools of program options reading in programming languages. Those who have a main method where arguments are explicitly mentioned in the method signature, and those who have another way of reading the data. Go has a main method, but it has no arguments in its signature - you read the program arguments from os.Args (which requires you to import the os package).
Elixir is fundamentally different than many of the programming languages most people use.
In C program arguments are part of the main method signature.
Sometimes when writing c++ programs I have some textual data that I want to use in the program that I want to be part of the executable instead of in flat files next to the executable. However while developing it is far easier to have the textual data in separate files - instead of in source files as strings.
Splitting strings in cpp is a bit different from high level languages
Use the boost library to trim a string in cpp
It happens to me at least once a week. I meant to make a topic branch. But I dove into the code too quickly - and suddenly I am a couple of commits into what at the moment seems like an important feature or bugfix, and I realize - I have committed to the master branch. This is a big no no in our company - bypassing code review, and a push on master most often means instant deploy.
I try to learn a new thing every day. Sometimes it is a big thing sometimes something small.
In my quest to get better aquainted with my new editor I decided to make some intelligent keyboard shortcuts for my blogging repository. I decided to have one keyboard shortcut that could publish the current draft (with jekyll publish) and one to create a new draft (with jekyll draft).
People joke about that I change my blogging platform and editor of choice only to have something to write about. And I guess I change both more than most people. My changes of blog engines may be a subject of another post.
Like so many of my colleagues I have a disease. I think it could be called “Idea Induced Domain Hogging”. You know that thing that happens in three easy steps. Develop gets idea, developer buys domain, developer proceeds to do nothing. What happens next depends on the individual. Sometimes you realize your mistake after one year, and stop paying for the thing. Sometimes you actually do real work and put something into the world - maybe someone actually uses it … But most often - the domain is forgotten until a reminder is sent (and my registrar sends them a lot).