Wednesday, November 29, 2017

Thoughts on the "Coding Craze"

Recently, a huge amount of emphasis has been placed on exposing kids to programming.  Bill Gates and others have had a lot of influence toward this, and many tools are now available to assist teachers with bringing coding into their classroom.  It's a very good thing, as it draws attention to a STEM-related career path.  However, there are dozens of pathways one could take in an IT/tech based career and coding is only one option.

I do not know any programming languages.  What I once knew about C++ and Java I've long since forgotten.  To be frank, I don't like programming.  I find it boring and frustrating, and because I didn't enjoy it I never spent time trying to improve my skills.  That did not rule out an IT career for me.  My concern is that with such a strong emphasis placed on programming, the kids who don't find it is "their thing" will see that as the only option for a technical career and will write off anything else.

My "thing" is networking and infrastructure.  I get excited about configuring a switch (saying you are "programming" a switch is a misnomer), setting up a new VLAN and designing an address scheme, or setting up a firewall rule.  I even enjoy the challenge of trying to get a wireless infrastructure to play nicely in a building that couldn't be less friendly to RF environments.  None of this is going away.  Even with the push to the cloud, you still need a solid infrastructure to access those remotely hosted resources.

Some really enjoy the server side of things.  Those cloud resources you hear about--they're not magic, there are teams managing servers in massive data centers.  Take our student information system, for example.  It is cloud hosted, but the team in charge of that needs to maintain backups, perform updates as necessary, maintain the system for redundancy and high availability, even migrate to newer hardware when replacing aging servers.

Another student may find they love web design or graphic design and wants to make a career out of that.  Maybe they want to be an engineer at Lenovo, Apple, or Cisco deciding which components to use and how to best design a new device for proper performance, longevity, serviceability, and usability.

The possibilities are indeed nearly endless.  Unfortunately, while they may not get completely overlooked, very little attention is drawn to them.  While coding is one great option, it is not the be-all-end-all of careers in technology.

Monday, November 13, 2017

ChromeOS Native Printing (Integration with Windows Print Server)

One of my few gripes with Chrome OS for years has been how printing is handled.  Up until recently, the only option was to use the cloud print service on your print server.  It was clunky, time consuming to setup, and prone to issues.  Upon troubleshooting issues with my current setup, I discovered that they released a better option which allows ChromeOS to natively communicate with a printer without requiring the cloud connector as a middleman.

So, here's how to set it up on a print server running Server 2016:
  1. Install the LPD service on your print server.  You may already have this if you have Macs in your environment since it would be used for printing from Unix-based operating systems.  We do not, so I had to install it.  It's quick, and there is no additional configuration necessary.  Just add it like you would any other role or feature:

  2. In the Google Admin console, navigate to Device Management > Chrome > User Settings, then select an organization of users to deploy printers to.  Scroll down to "Native Chrome OS Printing":

  3. Click Manage, then "Add a Printer".  I used the following options to add a printer shared on my print server.  The IP address in the last section is the IP of my print server.  "/CBRSDITLaser" is the share name of the printer on that server.



  4. Save and you're done!  I have PaperCut's free print logger installed on my print server.  Originally, print logs from Chromebooks were useless because they would all show up as coming from the service account that I had setup for Chromebook printing.  Unfortunately, they're only slightly better.  They don't show a username, but they do show the device's IP address.  In my environment, I can narrow down the source of a job as long as too much time hasn't gone by since that IP will tie to the username in our web filter logs.