Windows Deployment Server is free with normal server licenses.
It can PXE boot, load in all sorts of drivers and is really smart. I prefer it to SCCMs version. There is a book on how to set it up, I can’t recall the name of it right.m now, buts its step by step and is baller.
You don’t want to do a golden image that is sysprepped and then layed onto new machines. You are asking for trouble imo. Plus make new images takes forever and is really more dependamt. With WDS your golden image can be applied to any make model and can be confided to installs something (or not) depending on make model or if it’s a laptop/desktop.
If you have a ton of Lenovo in house, it gets ‘slightly’ trickier with the way they store the more info in the bios/wmic. But they cover that in the book.
Edit: https://www.amazon.com/Deployment-Fundamentals-Vol-Deploying-Microsoft/dp/9187445212/ref=nodl_
That Mykael Nystrom really really knows his shit.
Steve McConnel wrote a good book about estimation: Steve McConnel's Software Estimation: Demystifying the Black Art. It's very possible, if a bit boring. I used the book to estimate several projects of 6-12 months and 2-4 developers. The estimates turned out to be fairly accurate. Unfortunately, nobody cared.
It turns out that in the corporate world people are not interested in real estimates. What they want when they ask for estimates is:
Since inquiries about estimates are really politics, the approach in the question is a very good one. Estimate only small things and don't do long estimates. This will direct the question to the product owner, who is good at politics.
But yeah. If you work for NASA and want to put a human on Mars before China, do pick up a copy of that McConnel book.
I'd recommend getting a copy of Software Estimation: Demystifying the Black Art and give it a read.
The question you are asking about "how long it will take" will depend on the developer and the requirements. The requirements given so far are really vague... there isn't anyway to break them down into meaningful tasks. The developer is a hypothetical which is likely an optimistic model that doesn't match any real person.
There is no unofficial guideline because the project you are describing is new. What type of nav bar do you want? What libraries is the developer familiar with? Do you have a graphic designer? How long are you going to debate which color of blue the back ground should be?
Hopefully someone has something a bit more current, but Petzold's Programming Windows is (was?) the win32 bible. There are newish reviews on Amazon so it looks like it still floats a few boats.
Not an expert but I have read a lot of posts saying that 2016 is still young. Take the 2012 first. I am currently reading from this book and I find it great :
https://www.amazon.com/dp/111885991X/ref=tsm_1_fb_lk
You might want to pair it with : Learning Powershell in a month of lunches. It's a bestseller on Amazon and highly recommended.
Edit : what did you use for CCNA ? I have started it in the past but I find the prices exorbitant for seminars !
You can't do it this way. Linux is too big to learn everything sequentially in small steps. And it's not very practical. If you want to learn in a way that is practical and sequential, check out this book for Red Hat certification: https://www.amazon.com/RHCSA-Linux-Certification-Study-Seventh/dp/0071841962/ref=sr_1_3?dchild=1&keywords=red+hat+certification&qid=1594663391&sr=8-3
I would suggest the following:
1) Know how to install your favorite Linux distro. Do it several times so you are very familiar with it.
2) Learn how to boot into Linux manually with Grub.
3) Set up a firewall using firewalld, iptables, or nftables. Script it.
4) Learn how to start, stop, enable, and disable system services with systemd.
5) Add users and groups. Add user to wheel group.
6) Gain system access with su or sudo.
7) Learn the command line. It is your friend.
8) Learn the basics of Vi since it's on every Linux system.
9) Find your distro's documentation and get an idea of what's there. Pick out something that interests you and do it.
10) Figure out something you want and will use a lot. Do it in Linux.
Well, one option is Charles Petzold's book. It's a bit date now, as it came out in 1998, but a lot of the core API is the same (file operations, threads, dealing with Window messages etc.).
EDIT: I just remembered that I bought another book that's not quite as old: Windows System Programming, 4th Edition.
I thought they were both pretty good really. Thought the last one (obviously) has some newer stuff than Petzold's book.
Thank you for the post.
>This can be very challenging if the manager is a non-technical guy.
The company creates industrial automation automation solutions and my manager not only manages software but also other facets of the product. He is an aerospace engineer by training. He told me in my first meeting I have steep learning curve ahead of me but I should not panic.
>....you should look for mentorship outside and bring the knowledge in.
How do you suggest doing this? I am thinking of reading Code Complete and asking questions on the Software Engineering Stack Exchange website.
Steve McConnell has a good practical book on software estimation. I recommend it very much.
Software Estimation: Demystifying the Black Art (Developer Best Practices) https://www.amazon.com/dp/0735605351/ref=cm_sw_r_cp_apa_i_9mCKCbTFMH4XK
Nice article. I'd like to see you do one about a topic other than Moya, though. I feel like the Moya fans already know Moya, and are specifically using a framework like Moya in order to not fully learn how something like URLSesssion works, let alone FRP.
I recently did a PR on someone's project that had implemented Moya and it was my first introduction to it. TBH I was not impressed and would never recommend someone using it again.
I couldn't believe that such a popular (from my view) networking framework has Alamofire as a dependency. The creators of Moya really need to read this book
If you are curious about his (and Steves) motivation I recommend the book Hackers . I agree some people acquire wealth to compensate for tiny ****s, but there are other reasons
So, to clarify, your main purpose in learning linux is to learn the operations side so you can manage your webapps yourself?
I think you'll be a bit disappointed.
RHCSA/RHCE certification material will cover the fundamentals you will need to know, but not the methodology which is what will spin your wheels the most.
It is not linux related, but you may find value in the considerations covered in the second volume of the Limoncelli books.
Invata pe cont propriu, daca nu stii React/Vue/Svelte incearca sa vezi cum e.
Invata despre programare in general, de ex. cartea Code Complete sau despre limbaje Seven Languages in Seven Weeks
The possibilities are endless.
It's not a PowerShell book. It's a programming book which also applies to PowerShell.
It greatly changed the way I code/script for the better.
https://www.amazon.com/Programming-Windows%C2%AE-Fifth-Developer-Reference/dp/157231995X
The Petzold bible for all things win32 and C.
https://www.amazon.com/OpenGL-Programming-Guide-Official-Learning/dp/0201604582
Some version of the red book for OpenGL
Take a look at WinLamb source if you want to see how to build a native GUI.
As for books, Charles Petzold's Programming Windows is the classic reference.
Some answers seem to treat estimation like it's easy. It's not. Entire books have been written about estimation. If there's any programmer in the world who can estimate accurately or even close, I've never encountered them.
There are two tactics I've used to mitigate the challenges around estimation:
Regarding #1, I figure if I'll never be able to estimate accurately, at least I can try to make estimates a less important part of the picture. Probably my most successful tactic in this area is to try to only take on projects that last a matter of days. If a project will take more than a matter of days, then I try to break that project up and identify a sub-project that will only take a matter of days. That way, if I estimate that the project will take 2 days and it really takes 4, no one has "lost" very much and nobody's too upset (especially if I let my stakeholder know that I have very low confidence in my estimate).
Regarding #2, obviously all estimates are based to an extent on historical data, but there's a little more to it than that. When I work on a project, I break the work into individual features. I have a sense for how long a feature will take on average. Even though some features take an hour and some features take three days, a feature takes some certain amount of time on average. If I think the average amount of time I take to build a feature is half a day and my I can see that my small project has 5 features, then I can estimate that my project will take 2.5 days. Obviously there's a lot of room for inaccuracy in this methodology, hence tactic #1.
If you really want to go deep on estimation, I recommend Software Estimation: Demystifying the Black Art by Steve McConnell.
The problem with a lot of these courses is the tell you what to do, not how to think. If you already know how to think, these courses can have value, because they show you how things are done with other tools and libraries.
But, have no fear! You can learn to think like a software developer. You need to take courses geared toward that (if that works for you) or read books that teach you how to think like a software developer. My favorite book is [Code Complete])(https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670). It is very practical, with a bunch of checklists to help you organize your thinking.
Check out the book Code Complete. It breaks down not only how to solve problems, but has tons of checklists that you can keep handy to help you think through the steps.
I would highly recommend reading a book like Code Complete which breaks down step-by-step how to construct classes and how to define methods.
Scanned the first 50 pages on Amazon's preview. Looks nice.
Got to the end and saw the index was at 880 pages.
Dude, no one is reading something thicker than 250 pages softcover. My Cert books aren't even that thick.
You got a TL;DR?
I like that you call it a dark art because I read a book called Software Estimation: Demystifying the dark art a long time ago.
https://www.amazon.com/Software-Estimation-Demystifying-Developer-Practices/dp/0735605351
Programming is largely a practice in managing abstractions and putting those abstractions at the right levels to make the code easy to understand. Stylistically, I don't usually want my main code to need to dig into the colors of the jackets, I want to be able to render/display the jacket information in a more abstracted way. I'd actually recommend something like:
System.out.println("Jacket 1: "+jacket);
and then implement the toString()
method on Jacket, which returns a string. Having display
call System.out.println
in the method can create complications if we want to switch to a logging framework for example.
If you do have a display method, you may also consider passing it the output stream (perhaps a little contrived here, but very reasonable when accessing a database).
jacket1.display(System.out);
...
public void display(PrintStream stream) { stream.println("The " + color + " jacket is a " + size + " size."); }
These are good style questions, and I'd highly recommend the book Code Complete for some practical considerations on how to structure code in a readable and maintainable manner.
The Practice of Cloud System Administration
It covers a lot of the same material as the google SRE book, but (in my opinion) from a more approachable and realistic point of view for people who are operating at less-than-google scale.
Try amazon smile to donate to a charity of your choice automatically at no cost to you!
https://smile.amazon.com/Practice-Cloud-System-Administration-Practices/dp/032194318X
^^^I'm ^^^a ^^^bot ^^^and ^^^this ^^^action ^^^was ^^^performed ^^^automatically.
Can't get into specifics: These are the published objectives for the EX300 concerning what you are asking:
NFS
Looks like the first object speaks directly to what you are trying to do. As it is an objective, it can be on the exam.
I can also say that as an instructor for taught the RH254 class (the EX300 material), the files you are trying to manipulate (idmapd.conf and /sys/module/nfsd/parameters/nfs4_disable_idmapping) were not in the course content.
Neither were some of the options you are trying to use in your exports file.
Pick up Michael Jang's book (seventh edition). As the EX300 is on its way out, you can get it for under $20:
An estimate is not a commitment. This needs to be understood by both you and the person you're giving the estimate too.
When you have those 'unforeseen issues' - communicate those problems to the person who is handling resourcing promptly. This will help adjust the estimates and forecasts for when things are done. That's the main thing with estimates - they're used to try to get an idea of when things will start to come to gather (and in some cases, identify the critical path of resources).
Give Software Estimation: Demystifying the Black Art a read. It has a lot of techniques for how to estimate. A lot of people are really bad at estimating tasks. One of the biggest mistakes is giving only one date.
If you are 90% sure that "this task may take a day, it may take a week" - then that's the estimate. At noon today, you'll have a better idea if its going to take the rest of the day or the rest of the week.
An earlier version of this was my bible for a long time
https://www.amazon.com/System-Configuration-Manager-Current-Unleashed/dp/0672337908