caw

Refresh cycles depend on 3 values -- end of warranty, end of life, and end of support.

If you're end of support, you have no bug fixes, no technical support, and very limited part availability. You probably won't be running EOS hardware anywhere in your datacenter without a very defined plan to migrate off of it quickly or it's in a lab somewhere no one cares if it dies.

End of Life is when you can't buy the hardware anymore, so you start (or have already started) with the next generation of hardware. Depending on the policy, this could be the oldest hardware you have. You'll get the new stuff in and migrate over, and get rid of these machines most likely once they're out of warranty. Maybe you'll keep this hardware until EOS for low-priority work.

End of Warranty is the last major date, and it depends on date of purchase of a particular piece of hardware, rather than a product line. If you're on a frequent refresh cycle, once the product costs you money to repair then you'll get rid of it. You'll buy a warranty that most likely matches your depreciation cycle - 4 or 5 years. If you choose to keep machines that are out of warranty they start getting downgraded to less critical roles, or are scrapped as soon as they break. Repairs are variable costs in terms of parts and labor, and that doesn't play nicely with budgeting to manage a machine.

In general the harder it is to replace a single piece of equipment or the more expensive it is, the more likely you'll be running until EOL or EOS. Fileservers and networking (especially core networking) will be kept longer than cheap web servers.

EOW, EOS, and EOL all vary depending on vendors and product lines. It's the reason Dell and HP has a separate business line of desktops and laptops, because the EOL and EOS dates are known in advance, and you can standardize your equipment even when purchasing in multiple batches over 2 years. This reduces how much compatibility testing you have to perform, which is really beneficial for huge deployments.

I'd say the biggest things are: consistency of habit, finding something you enjoy, and you can't outrun a bad diet.

On habit consistency - start small. People get super depressed because they didn't work out three times that first week. Start with once a week, see how that works for you. Can you build in a second time that week? Do you need to change what time you do the activity, like before work instead of after? Try that and see how it works for you. Make things easy for you by setting your clothes out the night before so there's limited inhibitions on doing the thing you want to do.

You'll also need to find something that you enjoy. I'd personally favor a less optimal workout (in terms of working muscle groups, not increased risk of injury) that you enjoy over super-max-get-shredded-tomorrow that's a slog. You'll slowly build into it. For me, my activity was martial arts, I moved away from the dojo and got into weight lifting. I really didn't care for bodyweight fitness, and would find myself looking for excuses to skip or cut the workout short. Be careful when you compare yourselves to others, they could be much further along than you and had different constraints.

The third thing is diet. There's tons of articles on proper diet, and for me that's too much stuff to get into at the beginning. What I did was write down and calculate calories for two weeks at the beginning. The first week I ate normally how I felt like. The second I tried to make slight adjustments, still within the realm of things I would eat (basically the "eat this not that"). Those changes were enough for me to get to my desired calorie intake. I don't count macro nutrients, I don't weigh food. It was super intimidating to jump into that, and I didn't want to drag my significant other into my food changes. That being said, maybe entering everything you eat into MyFitnessPal or similar would be helpful for you. Maybe a defined diet regime with preplanned meals is something for you. A friend of mine pays for FancyHands or similar and just sends pictures of what he eats to them and they'll rough out the calorie count into his calorie tracking app. My relative preps everything on Sunday for the week, weighs food, and will not deviate from the diet even for the holidays. It's a bit of an experiment, going back to consistency of habit and something you enjoy.

I'd check out /r/fitness, /r/bodyweightfitness, /r/MealPrepSunday/, Strong Lifts, and maybe 4 Hour Body (a friend of mine swore by it, lost 25 pounds) as just different resources you could expose yourself to. You could also decide to do martial arts or basketball or tennis or whatever other sport.

Sugar is sugar, but honey is interesting in the flavors and aromas it can provide outside of your standard white sugar.

Just to add if anyone is interested in honey as a sweetener - What dxbydt was saying with honey being ~$8/lb is a good price for identifiable flower honey. Wholesale is roughly $4-5/lb, depending on varietal.

There's a significant range in flavors and aromas depending on what type of flower produced the bulk of the honey. Don't need to avoid anything on colors, it's primarily based on what type of flower is used to produce the honey. Try a sampler, most apiaries/honey specialty shops will sell you a small container of each varietal they have. Avoid heat treated honeys, heating the honey to have it pass through a filter will get rid of a lot of the aroma. You'll see a lot of "raw, unfiltered" at specialty shops.

If you're interested, you can ferment meads with a minimum of ~1.5 pounds per gallon, depending on how strong you want the resulting beverage.

We moved everything from SOLR to Elasticsearch about a year ago. We were already using Elasticsearch for data visualizations, but SOLR was our text search. Elasticsearch supported that, and we were able to add more language analyzers to support our use-case.

On the admin side, SOLR was a black box to everyone but one person on the team. If a node dies, there needs be another election, and Zookeeper needs to be updated. Restart nodes too fast and we ended up masterless a few times. Elasticsearch is much much better on leader elections and backups, though status going to red on new index creation is obnoxious. That supposedly will be fixed soon.

When employers talk vacation it's based off 8-hour business days. So 3 weeks is 15 days vacation, or 120 hours if your work days aren't 8-hour based like shift work or factories where you may work 4 10hour days per week.

How long ago was that? We just switched in January and it's been pretty reliable.

As far as Datadog goes, it's the most team friendly dashboard system we've used. We had a specialty monitoring system for one application stack previously, and no one made custom dashboards there or even just looked at the data. Now we've got custom dashboards out the nose and we're gradually consolidating to a "best of" dashboard for each service.

Only if you buy the newest edition; an older edition should work fine for self-study since there's no classes to keep up with, and OP won't need the online component. I'm sure there's significantly cheaper copies of older editions where people just want to get that behemoth out of their bookcase.

If you don't get a lot of responses here, I'd search reddit r/diy. Motor home/trailer renovations show up periodically. In the comments they'll share why they setup things in a particular way or what they might change.

My employer does payroll and benefits through a 3rd party provider. This provider has a nexus in my state, which allows me to claim local taxes as well as get a healthcare plan that meets my state minimums as well as has providers in my area.

Technically I'm a dual employee of the 3rd party payroll company and my employer (My W-2s have the payroll provider listed).

The problem with full follow-the-sun work is that it assumes the work can be performed in discrete quantities that are independent from one another. If you have overlap in tasks, then the coordination overhead becomes higher and more costly.

I used to use a Leap at my previous job, and have an Embody at home. I tried the Aeron at a store prior to purchasing, didn't see what the fuss was about.

Overall I like the Leap and Embody a lot. From what I can remember about using it, the Leap v1 had a few more adjustment points than the Leap v2. Both v1 & v2 were comfortable, had all the adjustments I needed to get proper ergonomics. I ultimately picked the Embody for home because while the Steelcase was good, I didn't want to spend 8 hours in the work chair and come home to sit in the exact same chair.

The Embody is definitely more of a flexible chair, you feel it move when you move in it. This has the side effect of feeling like you'll tip over if someone stands behind you and puts weight on your chair back (e.g. shoulder surfing and resting on your chair back). I don't like the arm adjustments as much as the Steelcase v1 Leap, there's no angling -- it just gets closer to you as you raise them up higher. Overall the Embody is very comfortable, and with working from home I use it 8-10 hours a day now. It holds up great.

Adding to "Don't run bower/npm install/update on production" - a lot of package managers have a local mirror available and you can point your build server to it. This gives you some redundancy if the public mirror goes down, and also faster downloads within the network. Bandersnatch mirrors all of pypi, there are some others that will just mirror the parts of pypi you need and fetch new packages as you try to pip install things that don't exist in its local cache.

I've worked two different on-call systems. The first was an enterprise company with a very defined process. 1 hour of pay for every 10 on-call (even if you're salaried, they figure out your hourly pay for this). Must be able to respond and/or get into the office in 1 hour, otherwise they call your manager to get someone working on the issue. Our 24/7 support would triage all issues before escalating on the on-call engineer--they were able to resolve most issues. Rotation period was roughly 1 week in 3 or 4 on a volunteer basis. We did have a group of software engineers who had an on-call rotation for the internal applications that powered the business. If I needed additional support for the application I could tell our 24/7 support folks to page/call them and they would hop online, which was needed on rare occasion when I couldn't fix an application error or a bug slipped the manual and automated QAs.

My current on-call system is considerably different as a startup. Most weeks there will be no pager alerts, some weeks will be particularly bad because something fell out of stability due to some other changes. There is a primary and secondary on-call. Each level has 20 minutes to respond and get online before it escalates (no office requirement since we're cloud based). The rotation goes through devops and all the software engineers, so you're on call for 2 weeks in 8-10 with no extra pay. I wouldn't recommend this method of scheduling because it's mandatory for all and some people don't take the duties seriously because nothing bad will happen if you let your pager slip to the next line, other than irking your coworker. There's no incentive to learn how to do the repairs or do them. I've seen a lot of "Oh my phone was off, I didn't realize I was on-call" that never happened at my previous job with the volunteers for extra pay. Having the secondary is nice because it is a guaranteed person you can escalate to for help on a complex issue, and they are available if you need to be indisposed for a short period of time.

About your specific questions: Your on-call duties are to communicate, fix what's broken, coordinate any additional escalations that need to happen, and most likely host the postmortem. Nothing more. Update your status page, send out an alert internally that X is broken, etc. When it's fixed and normal service has resumed, communicate that as well. You're the point of contact for anyone with questions about the issue, not anyone you had to bring online for a fix because if they're interrupted they're not fixing.

Don't start non on-call work. Fix to the extent that you know how and will make it stable until business hours. Not everyone has coded every system and knows the "permanent fix" for every issue. Your priority is based on what is broken and the business criticality of it. If multiple systems have failed, you fix the most critical ones first, which are normally the customer facing ones. There should be no "existing on-call tickets" because on-call bandaids and makes a high priority issue in the normal work queue.

If on-call can't complete the work in a reasonable amount of time, it may make sense to raise other people who can help. If it's going to take you 4 hours to get the $CRITICAL_FUNCTIONALITY back online, but getting Joe to help you will only make it take 1, then by all means try to get Joe if he's available. Again, based on your rotation he may not intend to be available, may not have his phone on, and may not want to take the call.

If you're dependent on 3rd parties, your application needs to take that into account. If you wake up because the external API is down and your functionality is down because of it, all you're going to be doing is losing sleep waiting for it to come back up to send out the all-clear. This changes somewhat if your external API comes with a SLA and a telephone number -- by all means call and start their triage chain.

A good thing to have is a sync up meeting with the on-call folks so you can establish patterns in the alerts that may not be evident by any one person.

It also has some other benefits, where you can service traffic coming from different directions. When you drive on the highway and get off on an exit to get gas, most of the time you'll stop at the one on your side of the road so it's easier to get back on the highway. You also avoid having to make traffic modifications to deal with the queue of cars trying to make a left into the Starbucks.

Along a similar vein - baking. I consider it different than cooking because you're not getting a meal out of it, but rather a dessert or snack. Work and friends are good ways of not having to eat all of it yourself. Free cookies in the breakroom tend to vanish quickly.

Lots of options here too, even healthy ones.

If you're more of a science-y type, once you get familiar with one recipe, you can modify just that recipe. I've modified a banana bread recipe to have less butter and sugar because I make it once or twice a month and play with it every time. You get a feel for what the consistency should be like to make a good finished product, and then bake it.

Config file changes rather than code changes. Version of the software stays the same, so you just have to restart it.

> When you are the “Uke” you are taught not to give feedback to your partner.

Maybe in aikido, as I've never done it, but in the martial art I practiced for a while uke was feedback. The attacker sets the tempo for the technique, reacts to the tori's strikes, and while they're not supposed to apply the movement for them - they can lead the tori in the correct movement and suggest openings by being strong in some areas and weak in others.

While sharpening a movement, after both sides have some level of skill, they can provide feedback as to weak points in the technique - "I can stand up here, you don't have enough pressure or you haven't moved me off balance enough".

None of this feedback has to be verbal, but you can learn the techniques on both sides. Similarly, while people should learn from small failures, you don't want a catastrophic failure where you go and break uke's arm because someone didn't tell you that you were doing the wrong technique.

How is building a Vagrant box via Ansible configuration any different than building a Docker container with a docker file? You can use both tools to build an image once and then rebuild for the updates. I don't see how the tool in any way violates that constraint.

What is this rule to only build once? I can see not wanting to create multiple artifacts of your codebase, but with machines it is possible to continually update them and sometimes desirable as well. In the "cloud" world, you can arguably rebuild a server every time it needs updates, but at the physical level you don't always have capacity to absorb the hit of rebuilding multiple boxes at once. The physical servers need to get updated and managed post-install.

There's also libcloud, which is a unified API https://libcloud.apache.org/

Some AWS specific functions, particularly for newer products or options, aren't always there immediately so you end up having to use boto in those cases. You also sometimes use provider specific options on functions, so it's not totally write-once and ignore.

I have an Evodesk, which is the cheaper version of the NextDesk. I picked it because I was able to get a curved work surface without a significant added cost, along with a memory controller (save your height settings and 1 click adjustment from sit-to-stand), and a cable tray.

It's sturdy enough for my laptop and 2 monitors from my sit height (~25ish? inches) to my stand height (~46? inches). The cable tray was a bit difficult to fit a surge protector into but I eventually found one that worked. The top is a bit different from normal desks, but it feels fine to rest against and use my laser mouse sans mousepad.

Most of my coworkers have some variant of the Geek Desk.

Having somewhat recently added Hubot to our own company chat, I'd say let it run its course. The first day I added Hubot (which out of the box has some "fun" features like gifs and images), everyone was sidetracked with it.

With the first week, it still had a ton of abuse, but that mostly tapered off. Now it's only used every once for comic relief.

So recommendations: Do nothing. Getting aggravated shows the coworker it's getting to you and will only entice more childish behavior. You could also squelch the bot user (not sure if Skype supports a user mute) or join a different channel and tell people who need you to find you there.

Attempting to kill the bot could make it seem to your coworkers that you're against any sort of "fun" or are super controlling, and may also backfire with your boss depending on what "respond to certain skype messages" is for your company, which I'm guessing is some basic ChatOps features.

If you're still super against it, you could always bring up with your boss on how it's impacting your ability to do work during your next 1:1.

Is it popping up halfway through or when it thinks you're mousing over to close the tab? Sudden upward mouse movements trigger some of those javascript retention popups, even though you were just moving to the scroll bar or something.

But while we're on the topic, the recent trend of "No thanks, I don't want to get all this awesome stuff" or "No, I don't want to become a master in subject X" buttons are very condescending.

Not sure what the minimum number of required employees is or how much extra this costs per employee, but there's payroll services like Oasis and Trinet that offer insurance in addition to their payroll.

Is there anything you feel like you should have learned or studied prior to bootcamp? (Either to make things easier or to have gotten more out of the program). A friend of mine is looking to join a bootcamp and comes from an economics background, so he's looking to get a good baseline before attending one.

Forms are definitely killer. OP - to save yourself some effort, start collecting the addresses of where you've lived and employer info for the past 5-7 years. This is somewhat of a pain if you lived in dorms at school and move back home every summer and into a new dorm in the fall. You'll also need references to verify each bit of this info ("Did rathalos work at X from dates Y to Z"), and I think a few character references ("Is rathalos of sound moral character?", "Do they use drugs?", etc).

On the plus side, you can duplicate references, so if you had a constant roommate just put them down.

Polygraphs won't apply to what's presumably a basic security clearance. There's a large cost to clearances and they won't get maximum clearance for an intern.

Depending on how long it takes to get your clearance, you may only have an interim clearance during your internship. This is probably for the employer to cover themselves if you encountered any sensitive information. It's highly unlikely you will be working with sensitive information, unless you go back to intern with them in the future.

One benefit of security clearances is that it is transferable, and is good for 2 years after you leave the job (without having to reapply). So you could intern, get a clearance, intern somewhere else next year, and then get a job after graduation that requires a clearance. If you're interested in certain aerospace or defense companies, this is a plus for them.

I'd like to say that means performers but I'm sure it's intentionally vague in the document -- security clearance applications are big on screening for potential things that you could be blackmailed or bribed for. Extensive debt, gambling, and drug use are all on the form. http://www.military.com/veteran-jobs/security-clearance-jobs...

I'm going to add my anecdata in here -- mid 20s, and I do not consume caffeine. I don't drink coffee, tea, or soda regularly. Nor do I drink energy drinks. No caffeine isn't a new thing, I've just never really drank it.

I haven't tried drinking caffeine regularly enough that I can tell whether there's a productivity boost to taking it. I'd like to say I'm pretty productive -- previous job was ranking me in top review buckets for my pay grade(s) for multiple years.

One thing I've noticed is that I'm a morning person, my best hours are 8am-12pm. Most of my coworkers (coffee drinkers) are afternoon people. Not sure if that's a trend or just programmer biases. I have noticed that pretty much all of my caffeine consuming co-workers need to have their coffee before I can ask them anything mildly complex. That could just be ritualistic behavior (get into work, make coffee, don't think about work until then), but could also be caffeine dependency.

I've done both an encoded data name scheme (what this is) and the cattle method (srv0001, srv0002, etc etc). SRV can even encode a bit of information like datacenter location. Avoid rack/row because stuff gets moved around. Airport codes are popular to distinguish datacenters.

As far as encoded name schemes go, and even with the cattle method, I like the physical/virtual distinction. It lets me know whether I can iLO/IPMI/drac or need to open vSphere/equivalent for when SSH doesn't fix everything.

Where I don't like encoded schemes is because your departments and users inevitably want to change the environment or service. Experimental/test servers tend to feature creep into production because "it works, let's just promote and build a new test box". Also you end up with weird combo servers with multiple services because "it's only this one thing and we can't wait for a new box just for it". So now the web server isn't just a web server or an app server.

My opinion is to keep naming however you're naming. I'd consider dropping the environment and most likely department. Encode that into the CNAME, or keep another database of ownership.

This article is pretty good on naming schemes: https://mnx.io/blog/a-proper-server-naming-scheme/

They may be if you have a team without much sysadmin experience. The way you develop could be the way you deploy to production.

These are the same teams that have overprivileged accounts for the database or sudo-enabled users running applications or chmod 777 all over the place.

Even things like Chef cookbooks have this going on. If you want to build from source because it's not in your repository, then you're necessarily going to need to drag in sbt or gradle. (see https://github.com/hw-cookbooks/kafka/blob/develop/recipes/d... as an example). Sure you could figure out the mirrors and download the correct binary from the website. You could also use this recipe to compile everything and then package it up to host yourself. (Both of these actions require writing custom recipes). Not everyone has time to do this, and this magical recipe you found online works great on the development server! Just add it to the production server and now we've just used sbt in production on a software team.

The ban was created after Tesla started selling, and now it only lifted the ban for zero emission vehicles as far as I can tell (didn't read the whole bill). If Ford or GM wanted to sell direct, they couldn't.

In the more generic case, states have these laws on the books to protect the local franchise dealers. These people buy cars from a particular manufacturer, usually multiple brands. In order to protect these dealers from the perceived threat that an automaker could come in and sell direct (thus undercutting their business), laws were enacted to require a franchise to sell vehicles. Thus Ford couldn't come in and sell vehicles unless they created their own franchise, which would raise their costs to be on par with the independent franchises. I think the justification for the protection is the local jobs and businesses.