[ale] Ruby vs C, a non-technical chat

[Chris Fowler]

I can't find the OP's original question so I only can comment based on this quote: 

> Any ideas on how to leverage a Linux and large datacenter centric career 
> into something with non-C coding? 
> 

I don't see "writing web apps" anywhere in that. Not to knock web apps, because if you read my recent posts I'm doing web apps and web services, mostly for 
administration. 

There was a time when I was all C/C++. "Scripts suck!" I only used Perl to automate testing of our C/C++ code base. As I wrote more I begin to write code that would have been written in C in Perl instead. This allowed me to easily and quickly test ideas. I then wrote the code in C. Eventually I did not write the code in C. I kept it in Perl. I focus on network monitoring, management, automation, etc. Almost all the code that really does heavy lifting is Perl. I have written some Python libraries for our projects too. 

Expect is one of my work horses. The Perl Expect module does more than you can image. We have it dialing remote sites to fetch alarms. I have it looking for stuff. I have it automating upgrades of devices that would take all day for one person. I have it running licensing systems and divvying out tasks. My SOAP interfaces will even take perl code as an argument and execute them. We have perl dropping T1 lines and bringing them back up, etc. 

The point is that IMHO to be effective in management of networks, devices, etc. you need to be able to automate your tasks as required. If you are working on a problem that is just taking too long automate that problem. I got sick of watching a Xterm during my day to check on dial up devices doing upgrades so I automated it and just read a file with errors at the end of my day. 

Anytime I see myself writing the same code over and over again I start writing APIs to abstract them. The calling apps become small. I can even do one-liners and do complex things. You get sick of writing SQL over and over and over again. 

My goal was to write a Ruby API for our system, but when I was unable to find an Expect module I knew automation would be a pain. Database was there. Python has pyexpect. That worked for me. 

It does not matter what language you use as long as you can use something to solve problems. I have had guys work for me that would spend 10 hours reading from a PDF and typing stuff into a web interface. I'll spend 1-2. I'll write the program that will grok the PDF and create rows in a database. The progress of data entry will not happen in those 1-2 hours, but one minute after I'm done! 

To learn a language you must need ot use the language. I've owned many 21 days books and even a few 24 hours books. Anyone can go through those. They key is to have a purpose. You need to keep coding when you are done reading those books. 

I'm not a guy who programs 8 hours/day. I'm not a guy who manages servers 8 hours/day. The best way I explain it is that I write code to solve complex IT issues. I can't overstate how programming has helped me solve some very complex IT issues I've had to deal with. Do you have to manage a device that will only show you failures via its web interface? Scrape it! 

Another skill is to see patterns and recognize opportunity to abstract those. I had to write an agent to submit alarm data to a ServiceNow ticketing system using SOAP. I spent some time working on this and it worked well. The customer wanted to add some variables to the SOAP message from the database. I got tired of changing the code of the agent. What I did was to remove all references to ServiceNow. I used Perl's eval with some formatting rules to support definition files. Now all they do is edit the file and then the program will use it on the next alarm. The potential here is that now I don't have to write an agent for Tigerpaw's ticketing system. All I do is just create another file and then the agent can use that file when sending to Tigerpaw. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20150805/d320cc3f/attachment.html>