This website shall finally reconnect with its roots – radices.
With the dawn of the new millennium a self-proclaimed Subversive Element has registered a bunch of domains. It was especially fond of radices.net and subversiv.at. Today, all these sites have been re-united and redirected to elkement.subversiv.at. But the site does not deliver on its promising name – I feel it became way too 'professional' recently. Historical content has been filed mostly under Physics (radices) and Art (subversiv). The category life displays some of the matter-antimatter collisions of these two worlds. Which also explains the category of the current article.
The Subversive Site was a Red Padded Cell, with Font Color = White, a so-called creative playground. The Element was aware that 'everybody' could read this but it did not care. The Merger of the sites was inevitable in the end, after a final detour of professionalization – when radices.net suddenly also hosted pages with IT Security links.
I have been a blogger, and I observed the evolution of other blogs: My anecdotal evidence shows that blogs live for about 1-2 years. If they are bound to survive they have to escape the matrix and to overturn their creators. A personal blog or website needs a 'Big' Idea. OK, not really big, but at least a-all-encompassing and abstract enough so that all the authors different threads and lines of thoughts can be silently tied together using this idea's magic glue.
My elkement.blog is relentlessly edited. It was a more philosophical site once, but I aim at following our punktwissen principles now. Articles should be concise, provide value, and perhaps also entertainment. There should be s logical connection between posts and my curated lists should help readers to find something 'useful'.
On the contrary, this site has more or less the same article over and over again – perhaps in disguise and interlaced with technical notes. It is all about my personal keeping the essence of Physics alive and useful for me. Since radices was originally a German-only science and philosophy site, the English version might not reflect this – but in the early articles on elkemental Force (at that time: Theory and Practice of Trying to Combine Just Anything) I recaptured these ideas.
So I do finally accept this – let elkement.subversiv.at have its way. This is elkement's personal site, and its primary topic is How To Learn About Physics And Why This Might Be Useful Or Even Edifying In Very Different Ways.
- Learning physics means to start somewhere in the middle. That's why a first Introductions to Physics lecture is always hard (if the lecturer has some modest mathematical aspirations). You need to look at the same phenomena from different angles, and only after a while – and some work – everything will fall into place. This process and journey of learning is rewarding in itself.
- The more related to mathematical foundations (of physics) a question is, the less googleable the answer is. You can find anecdotes, and examples, science sound-bites for entertainment. Of course you find awesome lecture notes to learn the fundamentals from Feynman Lectures to Landau-Lifshitz – but you need to 'learn' them. In contrary to the mantra of You Just Need to Know Where to Find Something (like: Google for error messages) I believe that really knowing about fundamentals without googling helps a lot with problem solving: You can walk through how a system should work, just using the resources in your head.
- Mathematics purges the brain, and this does not only help with mathematical problem solving. So I believe that the hackneyed problem-solving skills of science graduates are real (albeit it is difficult to assess the self-selecting nature of STEM degrees for people with natural 'analytical' skills). But the caveat it: Years of corporate work, powerpoint slides, office politics, distractions, pressure to deliver ad hoc can erode these skills. I have long-term tested different methods to keep physics knowledge alive and usable - and learned now that science might even provide some evidence, in a sense.
- I have been in 'cyber security' for a while and I have written lots of gloomy articles about our new smart world of automation and where everything (including heating systems) is turned into cloud-based services. Thoughts on all of this is still work in progress, I am working on internal consistency and unambiguity. I came into the world of IT as an experimental physicist, I was applying my training of troubleshooting complex 'analog systems' to digital systems. Despite the myth of crystal-clear 0s and 1s it was often better to treat them as blackboxes. I lacked the typical computer nerd's / enthusiast's background and started late – playing with Microsoft systems and Office VBA and the like. In spite of this Treat-as-a-Blackbox approach I like to understand as much as possible about a system. Yes, I know you cannot understand, yet build, a power plant, from knowing how to solve Maxwell's Equations (yet understand or solve issues in cyber security related to such power plants). Nevertheless, if I have the choice to understand something at all, I'd pick Maxwell's Equations.
Since years I am using an (angry) dinosaur as my web and blog logo. The dinosaur is from another era, and sometimes it cannot deal with 'modern' concepts of our 'smart', 'networked' world. But perhaps, it was part of this world for a while in order to overcompensate.
Now the dinosaur is getting more and more confident that its typical dinosaur activities might be more productive and positive than it thought before.
On science and technology
- I believe there is often a simpler, a more low-tech solution to a problem technology is thrown on.
- I sometimes call myself a geek but I don't understand this 'geek' movement of cheering science and technology - without any desire to learn any of the details.
- I prefer to work on seemingly mundane problems that somebody really wants me to solve right now.
- This explains why I discarded inquiries to participate in and profit from governmentally funded research projects.
- Yet, I often find a universe of intriguing puzzles when mulling upon a 'simple' problem.
- Learning about theoretical physics has a mind purging effect: It helps, no matter if I ever need the math directly.
On business and life
- If a business relationship does not work without a written contract, it does also not work well with one.
- Don't follow any advice by strategists and experts, especially if their primary role is to act as consultants and not as doers.
- If somebody has an opinion on something, I judge them on Skin in the Game, hands-on experience, and education - in that order. I keep this in mind when voicing my own opinions.
- I don't pay for leads - I endorse other for free, and I am endorsed for free. Not necessarily on a 1:1 basis.
On the internet
- The greatest internet-powered innovation in the workplace I have encountered is to work remotely.
- I am grateful that I started writing online before there were Likes and Comments. The point of writing online is to hold yourself accountable because others could read this on principle, not because you need feedback.
- The internet sharing paradox: The more information you share for free, the more requests for free information you get. Learning to say No is a key skill.
- No matter how eclectic you think your combination of specialties is - you will find people on the internet featuring the same combination. Just better. It's humbling and this is a good thing.
Sometimes I wonder why I had created a Tech category separate from an IT category. The two of them are interrelated closely as my recent Wordpress blog post on my so-called Data Kraken had demonstrated.
I call myself the Theoretical Department of our engineering consultancy because I am mainly in charge of software development, simulations, and data analysis – related to measurement data for our heat pump system (and those of our clients).
But there is one big difference between what I call 'IT-only projects' (like my PKI-related services) or engineering projects that also involve software: 'IT' is my tag for providing software-related consulting or software engineering related to somebody else's IT system – a system whose requirements are defined by somebody else. My engineering software is built according to my own requirements. My 'Tech' projects, IT-centered as they may seem, are not primarily about IT: They are about systems using, storing, and transferring energy. IT is just a tool I use to get the job done.
All things I had ever done as an IT professional turn out to be useful, and I am learning something new nearly every day – when thinking about 'energy'. Heating systems today are part of what is called Internet of Things – so IT security is also an important aspect to consider. In 2015 I used this website to finally transition to .NET (… finally, from ASP ?), and as a spin-off I also re-developed the numerical simulations for our heat pump system in .NET – representing every component as on object. 2014 I migrated our initially only Excel-based data analysis to SQL Server, and I have improved my 'Data Kraken framework' since then, adding visualization by automated Excel plots etc.
I still work for some select 'IT-only' clients - and it seems my 'IT articles' here just constitute a series of updates about the exact extent to which I still do PKI. If the occasional data analysis question comes up, any SQL, Excel, or .NET skills might come in handy in my IT projects - like querying a certification authority's database, or using a semi-automated Excel sheet to create a Certificate Policy Statement, following the RFC. But I don't advertise myself as a SQL etc. expert; I rather think I returned to where I came from, many years ago:
When I worked as an IT consultant, I had been asked over and over: How does a physicist end up in IT? There are very different reasons: The obvious one is that as a physicist you might have picked some programming experience. I had indeed contributed to the (mess of patchy 'local-community-developed') software for automating the measurement of electrical resistance of superconducting thin films many years ago, but this was not the main reason. I was an experimental physicist so I can't claim that my work was immensely mathematical or computational (and my job as 'implemented applied cryptography' via Public Key Infrastructures was not either). The main analogy is that IT systems of sufficient complexity are as unpredictable as an experimental setup governed by lots of parameters, some of which you have not identified yet – as was the manufacturing of thin films by laser ablation. I was simply patient, perseverant, and good at troubleshooting by navigating a hyperspace of options what might have gone wrong.
This might be either boring or frustrating for non-geeks. But I believe the grunt work of maintaining and fixing software is rewarding if this is an auxiliary task, done to support the 'actual' system of interest. Mine are heat pump systems, power meters, photovoltaic generators and the like. I want to understand and optimize them and so I am willing to learn new programming languages and spend hours on troubleshooting bugs with software vendors' updates. Just as back then I learn the bare minimum of Turbo Pascal to develop software for low temperature measurements.
In 2017 I am going to focus on maintaining (and bug fixing ?) Data Kraken und ich will work on making usage and 'visualization' of the numerical simulation more and more similar to Data Kraken.
Currently, Data Kraken has the following main features:
- Documentation of the sensors and log files for different loggers (Heat pump / UVR16x2, smart meter, PV…) in an Access database - a small proto-kraken per installed system.
- Documentation of changes to sensors and log files, such as: Shuffled columns in files, modified naming conventions for files, new or replaced sensors. For example, the formerly manual reading off of the surface level of water in the water/ice tank has been replaced with an automated measurement in 2016. So the input value for calculating ice volume moved to a column in a different log file, and was measured in different time intervals.
- A Powershell script grabs all log files from their source locations, and changes date formats, decimal commas and line breaks. (I found this to be more performant than manipulating every line later after the import to SQL Server).
- The Powershell script then creates an updated set of SQL scripts – one set of scripts and one SQL database for each installation / each client. For example, the CREATE TABLE or ALTER TABLE commands are created based on the Access documentation of measured values and their change log.
- SQL scripts create or add SQL Server database fields, import only the files containing data points not imported yet, and import their data to a staging table. Each SQL database can thus always be re-created from scratch – from CSV log files and the meta documentation (Access).
- Error values are modified or deleted from the staging table, as defined before in the Access database (and such in a SQL script): For example vendor-defined error values for not connected sensors (as 9999) are set to NULL or whole rows of values are deleted if the system was e.g. subject to maintenance according to other system's documentation.
- Finally, the most important script is run: The one that does the actual calculation of e.g. average brine temperature, energy harvested by PV panels or the solar / air collector by day, or daily performance factors of the heat pump. The script needs several levels of SQL views – all of which are re-created by the script.
- Microsoft Excel is used as a front-end to show values from tables with calculation results. One Excel-formula only simple table allows for browsing through values, and picking daily, monthly, yearly, or seasonal numbers.
- Excel plots are automated with respect to the fields (columns) and to start and end date. Existing plots can be copied (also from other workbook), then documented in a table. The documentation table can then be modified and is used as input. Color and line widths are still tweaked manually.
Weird as this setup sounds, it allowed me to develop and change the solution just in the right way – installation by installation, e.g. by testing the changes to log files after the control unit's firmware for one specific installation first.