Wednesday, June 28, 2023

Web Design: Make Duplicate Forms And Remove/Reset Them

 I don't know if anyone else would ever need or want something like this, but here we go. If you want to be able to create multiple forms on demand on the same page along with maintaining the ability to remove them or interact with them, then this is for you. First thing first, we need to make an HTML document.

<!DOCTYPE html>

<html>

<head>

<title>Some Stupid Form Thing</title>

Now let's get our Javascript on! I know I add some stuff that is not needed, but I'm weird.

<script type="application/javascript">//<[CDATA[

"use strict";

//I like to do a global storage object

var storage = {

    "formdata": "",

    "fid": 1

}

// function to store original form setup

function getformdata() {

    storage["formdata"] = document.getElementById("form0").innerHTML;

}

//Creating new forms

function addform() {

    var newform = document.createElement("form");

    newform.id = "form" + storage["fid"]++;

    newform.innerHTML = storage["formdata"];

    document.getElementById("formlist").append(newform);

}

// Removing forms, or reset the last form

function removeform(b) {

    b.parentElement.remove();

    if (document.getElementById("formlist").children.length < 1) {

        storage["fid"] = 0;

        addform();

    }

}

//]]></script>

</head>

Now that all the delicious code is out of the way, we need to create the body that this will interact with. It's actually fairly simple.

<body onload="getformdata()">

<div id="formlist">

<form id="form0" action="#">

Employee ID: <input type="text" value="" class="eid" /><button type="button">Do a thing</button><br />

<button type="button" onclick="removeform(this)">Remove</button>

/form>

</div>

<button onclick="addform()">Add Form</button>

</body>

</html>

Summary time. I am using a div as a container to create and remove forms in. Using the DOM we can isolate what we need inside of whatever container and use that to modify whatever with minimal navigation, no extra overhead of frameworks needed. I don't know why anyone would need this, other than the reason I made it that I'm not going to say. But there you go.

Comparing IT Jobs (Dedicated vs MSP)

 It's been a long and busy I don't even know how long. In a short while, I will be starting my new role as a Network Engineer, which sounds so intimidating that I am looking forward to the idea of being a newbie even on a technical skill level. I won't claim to be the smartest person in the IT room, but I will say I know my stuff well enough that even doing a new job at an MSP I received comments about how little help I needed and how few questions I asked. The job at the MSP did not last very long, almost got to 6 months. Either way, I had 7 years and 10 months as an in house IT Specialist and 5 months as a Field Specialist at an MSP. I would now like to take the time to compare those two jobs in hopes of helping people decide what route they want to go and maybe also help remove any rumors you might have heard with more solid experience.


To begin with, what is the difference? Well, in house IT Specialists are people who work for the company they are hired on. An MSP, or Managed Service Provider, is a third party company hired on to manage IT tasks for companies who either lack the resources or size to be able to hire on dedicated people. There are varying levels of hybridizing that can occur. My job as an IT Specialist also had used a third party company for network engineering and even for cyber security after a cyber incident. This means that just because a place has dedicated IT people does not mean they fill all roles in house, and also that an MSP may have to work with in house IT people.


Now to clarify my roles. As an IT Specialist, I worked for a local Board of Education. As a Field Tech, I worked for various car dealerships, as that is what the MSP I worked for specialized in. For transparency even further, I will say it was Effingham County Board of Education in Georgia and Proton Dealership IT (owned by Reynolds and Reynolds). With that, let's talk about the jobs.


Let's compare and contrast the two. As in house IT, I was more a part of the team. People were closer and more forgiving so long as they recognized you making the effort you needed to. Getting to know people is so much easier. As an MSP, I was an outsider. Anything went wrong with my company, being the face of the company it became my fault. Anything went wrong, it was easy to blame the "other guy." As an MSP, you really need to schmooze with people. This also means when you come across incompatible personalities, it can become a big problem very quickly. I know from my own experience of having one place absolutely hate me being there, while having another site where I got constant compliments about the effort I was putting forth. So as an MSP tech, you can do well with the gift of gab and some skill, whereas in house it is better to be skilled and let people come to appreciate that.


As in house IT, you will have better familiarity with your site(s). When there is one solution to dictate how things go, there will be some level of consistency, even if it's "layered" by different times, budgets, and ideas. Regardless, the original thought should be somewhere in there. This means once you learn the bulk of things, you can really drill into it all. As an MSP, you will have little consistency and a lot of variation. Great for learning but horrible for long term solutions. Most of the time it is either band-aid it or overhaul. Overhauling can be great because then you are going to know everything from the ground up. If you want a broad range of exposure without as much time to get into the deeper details, MSP's are strong. If you are more concerned with getting deeper, in house is the way to go.


As in house IT, I was more than just the "IT guy." I mounted TV's, put up projectors and screens, ran and terminated cables, installed cameras, drove moving trucks, loaded and unloaded trucks, spotted people on a scissor lift, sat down with people who were having mental break downs, moved furniture, and so much more I can't even remember. In house IT is used and abused to do everything and anything because you are there. It was often justified to me as "you know how real IT is." With the perspective of an MSP, I can now say yes I do. At an MSP if someone asks me to do a service they are not paying for, the answer is no. At my MSP I don't run cables, or mount TV's, or do anything really not essential to the job they pay me to do unless I'm trying to schmooze. And even then, there are some things I was told to say no to so they can't sue us because we are the "other guy." In house IT is the mentality of "it needs to be done and the manpower is here." You are extra manpower. MSP is the mentality of "pay me to do it or I don't do it." I have to tip my hat in the favor of an MSP and will take the time to say that if my bosses from my IT Specialist job read this that yes, I do know what an IT job consists of and you guys were the ones that didn't seem to know or understand where IT ends. Yes, I am still a little angry about all the extra I was asked to do at my IT Specialist job. I can say my job in an MSP was very clearly defined.


Skill sets are going to be a weird one to cover. As an in house IT Specialist, I needed technical knowledge. It seemed like every day I needed to know something deeper into our systems. I was not worried about what equipment was bought or who or how we contracted some stuff out. I was purely a worker with a job to do. I can say that I didn't "manage" much; maybe a project here or there. At the MSP, I needed to do things like work for getting orders of equipment ready, managing my stock of equipment, finding and contacting contractors, coordinating things with managers, etc. You have to actually work at some capacity as a "manager" or "lead," not so much for other people but for you, equipment, and time. At the MSP, I got more comfortable calling up support numbers, finding equipment, and making purchase requests, than I ever did as just an in house IT. It wasn't something hard to learn, but the level of comfort with it increases as you do it more.


Now time to talk about coworkers. In house IT had coworkers I worked more closely with. The skills seemed pretty set as to you could tell who had been there longer. We actually had someone hired on with virtually no IT experience who learned it all on the job and you could tell that most of what you got there was learned over time as experience. In house IT can have way more flexibility in skills because you need to learn there way. An MSP is different. Everyone there did have a varying level of skills, however everyone seemed to have a better grasp on a wide variety of technical knowledge. If it wasn't for the at times very surface level knowledge, most of the people at the MSP would be able to be higher up techs elsewhere. Some coworkers are very knowledgeable, but I can say that all of them are usually able to keep up in technical talk of so many different things. It's really like being surrounded by a lot of hobbyists.


Now let's get down to the part everyone is interested in. Pay and benefits. I have heard that at an MSP you get paid less than in house. Going to an MSP, I made more, however that was leaving a local government job which is already expected to pay less. The MSP job was also salary while the in house job was hourly. Both jobs offered health insurance and the government job was slightly cheaper if you don't count the option to get screened and not pay anything. Both jobs offered retirement, one as a teacher retirement (TRS) and the other as a 401k with matching. The bottom line is it's not so much dedicated IT versus MSP, but company vs company or type. Private pays more than public, usually.


Finally, let's talk about working as in house with an MSP versus an MSP working with in house IT. When I had to work with an MSP, we had meetings and lengthy. There is also a very good chance that something will be miscommunicated. In my experience, I had to help communicate basically the same information repeatedly to get the actual information across. It is nice for something to be "not my problem." As an MSP communicating with in house IT, it was actually nice for me. I had the information I needed sent to me. There were also points were I just needed to wait for the in house IT to do stuff. Both sides have issues, both sides have the advantage of each side having separate duties. Basically, it's nice to not be entirely responsible but it sucks to have to communicate across parties when communication does not go as expected.


Now, for the conclusion. Which is better, in house or MSP. It really depends on your personality. If you like going to lots of places, seeing lots of variety, and relying a lot on people skills, you will probably do well at an MSP. If you are the kind of person to get the job done first and foremost, a dedicated IT job would probably work better. If you clash personalities, you can fail pretty hard at an MSP.. If you want a strict job description, in house IT may disappoint or overwhelm you. To become well-rounded, I would recommend a hand at each at some point in your IT career to gain a variety of experiences.

Tag Cloud

.NET (2) A+ (5) ad ds (1) addon (4) Android (4) anonymous functions (1) application (9) arduino (1) artificial intelligence (1) backup (1) bash (6) camera (2) certifications (3) comptia (5) css (2) customize (11) encryption (3) error (13) exploit (5) ftp (1) funny (4) gadget (4) games (3) GUI (5) hardware (16) haskell (6) help (14) HTML (3) imaging (2) irc (1) it (1) java (2) javascript (13) jobs (1) Linux (19) lua (1) Mac (4) malware (1) math (6) msp (1) network (13) perl (2) php (3) plugin (2) powershell (8) privacy (2) programming (24) python (10) radio (2) regex (3) repair (2) security (16) sound (2) speakers (2) ssh (1) story (5) Techs from the Crypt (5) telnet (1) tools (13) troubleshooting (11) tutorial (9) Ubuntu (4) Unix (2) virtualization (2) web design (6) Windows (16) world of warcraft (1) wow (1) wx (1)