Hello, PowerShellers! During our migration and some of the inevitable database resets involved, many of you who were receiving notifications for new forums topics no longer are. You’ll need to re-subscribe. To do so, simply visit the Forums page, click through to the forum(s) of your choice, and poke the “Subscribe” link that’s towards the upper-left-ish of the page. If all you see is an “Unsubscribe” link, then you’re already good to go. Thanks again for everyone who routinely jumps in to offer friendly, helpful advice in the forums!!!
We’re in the process of emailing speaker invitations to those whose sessions were accepted for the 2017 agenda. **Please check your email and promptly follow the instructions to complete registration. ** In the event that a speaker is unable to confirm their invitation in time, we will move on to other speakers and sessions - that’s why, if you haven’t presently received an invitation, you still might. Once we’ve confirmed everyone, we’ll send out notices to any speakers who were not selected, so that you’re in the loop. We do appreciate your patience as we work through this process. Registration will open November 1st, and a draft brochure is available at http://PowerShellSummit.org. This brochure does include session highlights that may not have been confirmed, so they’re still subject to change. The Registration link at PowerShellSummit.org will show you the current confirmed agenda. For speakers who were regretfully declined, you’ll be able to register on November 1st. In the event we have a late speaker dropout - which happens - we may contact you about jumping in as a speaker after all, at which time we’ll sort out the finances if you’ve paid for your registration, typically offering a full refund of your registration fee. You’ll notice that Summit has become a full 4-day event - we’re unsure, at this point, if 3-day passes will be offered or not. We won’t make that decision until February 2017, assuming any space remains by that point. So we hope you’ll consider joining us for the full 4-day event, including new hands-on experiences on Sunday, a wider variety of deep-dive half-day sessions on Sunday, attendee-driven “Side Sessions” on Tuesday and Wednesday, and an amazing lineup for Monday.
So, after our nearly-2-day outage, which was due to a still-not-fully-explained Apache fail, we’re looking to make some changes. We need to migrate PowerShell.org to a different Azure subscription anyway, so this is a good time to change the kind of service we’re using. First, using Azure is non-negotiable. If your expert opinion is to use something else, please just don’t ;). **Update: **This might be changing. AWS could be an option. Second, our current environment is a classic VM running CentOS 6 (yeah, it’s old), WordPress, and MySQL. WordPress and MySQL are also non-negotiable, this isn’t about switching CMSs or anything. We use VaultPress for to-the-minute backups, but their restore process is a beast and has never been easy or reliable. What we WANT is the ability to more or less push a button and re-deploy the entire site from backup, ideally automated through some OMS trigger that senses when the site has crashed. Now, some caveats.
As you may know, Jeffrey Snover and I have, for some time, been on a “servers are cattle, not pets” kick. Meaning, servers shouldn’t be special, individualized snowflakes. They should be, in many regards, appliances. One dies, you eat it and make another. They don’t have names - that you know of. They don’t have IP addresses - that you know of. Oh, I mean, they have them, but you don’t know them and don’t care. Anyway, one thing that came up in a recent conversation related to DSC’s ConfigurationData blocks. Have a look at the MSDN documentation and tell me what you see. Go on, I’ll wait. You see **NodeName. **But damnit, if servers are cattle and cattle don’t have (known) names, what the dude is NodeName all about? Well, for one, it was a poor choice on the team’s part. I’d have called it - and this is giving away the punchline - **NodeRole. **Imagine that your “NodeName” was “SalesAppWebServerRole.” When you run your configuration script, you get a MOF named SalesAppWebServerRole.mof, right? Which you then checksum and load onto a pull server. And when you’re spinning up a new server to host that role, you tell its LCM to grab the ConfigurationName “SalesAppWebServerRole.” The server, when spinning up, makes up a name for itself. Charming, right? Cows think they have names. Sweet. Don’t care. It gets an IP address for itself, partially from DHCP of course, and partially by making up the other necessary IPv6 stuff (oh, and IPv6 is a thing now, so get on board). Then, presumably, it runs to the pull server, grabs the MOF, and starts a consistency check. During which, presumably, _it registers some known name with DNS or load balancer or something. _Now you know it’s “name!” Or the name you want to call it by, at least. Also presumably, your load balancer knows to remove or suspend the entry if the host stops responding, and to periodically scavenge stale records (remember, the node’s own LCM will make sure its entry gets put back, on the next consistency check run). So if the node dies and you spin up a new one, the rest of the affected infrastructure - DNS, load balancers, what have you - clean themselves up automatically (and DSC could be involved in that process, too). Anyway… the point is that ConfigurationData blocks can absolutely be used for cattle farms, not just for pet shops. “NodeName” is a misleading setting, but if you think of it as a role, which could be applied to multiple actual machines, then it makes a lot more sense that way.
With Ignite fast-approaching, here’s what’s up - and this is intended to be a “community post,” meaning I’d love it if you could add your own PowerShell At Ignite notes in the comments, including sessions you’re looking forward to! On **Sunday evening, **while not officially a PowerShell event, a lot of PowerShell glitterati will be at The Krewe’s annual gathering from 8pm. On **Monday evening, **the Atlanta PowerShell User Group is kindly hosting a meet-and-greet with myself, Jeff Hicks, and Jason Helmick. We promise to be educational; registration required (but free). Tuesday evening is the PowerShell Community Happy Hour (from 4-7; tickets required), including many of the in-attendance team members, most of the PowerShell.org Board, and a bunch of super Shell enthusiasts. We’ll have PowerShell.org and The DevOps Collective laptop stickers! **Wednesday, **I’m looking forward to PowerShell Unplugged with Jeffrey Snover and I, from 9 to 9:45am. This is nearly always hilarious and fun. Then, from 10-10:30, Jeffrey, Jason Helmick, and I will be signing books and handing out laptop stickers at the Ignite Bookstore. Finally, from 11-11:30, I’ll be signing FREE! books at the Conversational Geek booth (#571) (who have some amazing scavenger hunt prizes). And of course, please stop by the Pluralsight booth to say hi, pick up some swag, register your company for a free pilot subscription, and whatnot. So… what’re YOU looking forward to next week?
It’s a bit of a sad day at The DevOps Collective, which is the nonprofit that runs PowerShell.org. One of our Board of Directors members, Dave Wyatt, will be stepping down from his Director position this week. He wants to focus on his personal life a bit more, although he’s still going to be responsible for our public Build Service, and he’s going to continue contributing to the Pester project, so the community isn’t losing him entirely. Dave’s been a huge help, and a huge inspiration, at PowerShell.org, and he’ll be greatly missed. But our sadness is balanced by some happy news, too, as PowerShell.org Webmaster Will Anderson has agreed to fill Dave’s seat. Will has brought a great enthusiasm to our team of volunteers, is also a PowerShell MVP, and also resides in Canada. Will’s responsible for most of the photography you’ll see in the upcoming PowerShell + DevOps Global Summit 2017 brochure, and he’s been a great help in keeping PowerShell.org’s website up and running. So please join me in wishing our outgoing Director all the best, and in welcoming Will to the Board!
As a quick reminder, our Call for Topics is still open for a few more days! Summ. Summit is very much intended to be a kind of mega-user group, not a “conference,” so don’t assume all the “professional” speakers have taken up all the speaking slots. We want you to participate! In the meantime, while we’re waiting on the content committee to select topics and before registration opens in early November, I wanted to offer a peek at what we’re planning.
Remember that our Call for Topics is still open until the end of September, if you’d like to submit. And, from our Summit Alumni Slack channel, here are a few things people said they’d like to see…
I would love to see a session on what it takes to build a PKI infrastructure in support of PowerShell operations ( stuff liked passing creds with DSC ) - this is something glossed over all the time as if it is not a big deal but I think it can be quite challenging for a lot of people to implement.
Writing for Performance: Tips and Tricks to Write Faster Code
Compiled cmdlets - how to create them and why you might want to (this got a lot of thumbs-up)
Open source PowerShell hackathon. Either one multi-hour (2, 3, 4?) window where people can break into groups and work on some open source PowerShell extension, or two sessions, one at the beginning of the event and one at the end. The one at the beginning the presenters/organizers provide a set of possible project ideas to work on, and people interested can sign up/vote for projects which creates groups. The one at the end gives groups an opportunity to share/demo what they produced. Having a room where people can gather to work on it would be cool. These don’t have to be big projects. They could be small things, like knocking off one or more issues for an open source project. The end goal is to have a pull request submitted or a new project posted in GitHub or a new module submitted in the Gallery. _Now, to be clear, this isn’t a session - but you can definitely propose it. We have some longer time slots on Wednesday for panels, and this might be something you could do then. _
examples of real world DSC usage - that was a comment I heard from a number of folks this year
Practical Pipelines. ( Illustrate that release pipelines aren’t just for DevOps-practicing shops, or public-facing software )
Build plans (and tools, like psake)
Module design best practices (lots of thumbs-up on this one)
Working with Open Source Projects (as a Contributor)
Working with Open Source Projects (as a Maintainer)
Applying Agile Software Development Methodologies to PowerShell
Using for . (assumption: someone writes the equivalent of inspec wrapped around Pester)
And if you read the above carefully, you’ll notice that **we do also have some space for afternoon panels on Wednesday - so if there’s a group discussion you’d like to lead, propose it! **Just be clear in the description you submit that you’re proposing a panel. It’ll be up to you to recruit panel members, which you can do on-site. We’ll announce panels in need of panelists and direct them to you.
Jason Helmick and I were talking last night, and we got onto the topic of expertise and respect. Kind of, “once someone really gets to that expert level, and they surpass their teacher in knowledge, you really respect them.” I disagreed, and said, “no, I respect them the minute they start contributing to the world, and helping others.” We all, at some stage, get “outsider syndrome,” where we think everyone else is so much smarter than us, that we’ve nothing of value to contribute. But that’s never true. First of all, there’s this thing called a “birth rate,” meaning there’s always new people coming into the field. Second, no matter what your level of expertise, you’re in it, right then. “Experts” too often forget what it was like to be a beginner; a beginner knows, and can often relate things that another beginner can understand more readily. Take this wonderful post by Missy Januszco. Missy probably doesn’t consider herself an expert, although she certainly held her own at my recent DevOps Camp. And she certainly wasn’t the only one writing about open-source, cross-platform PowerShell Core that week. But she did it from a unique perspective, one that a lot of her readers can probably take a lot from. And she did it - instead of just talking vaguely about giving back someday, she just did, and did it well. PowerShell.org isn’t a curated newsfeed for a select few; its yours. So if you don’t have your own place to publish and share, email webmaster@ and let us set you up to write. Whenever you solve some problem, conquer some gotcha, or have a perspective on the latest PowerShell news, share. You definitely have something to offer.
As PowerShell begins to move into a cross-platform world, it’s important to really understand “why PowerShell.” What is it, exactly, that sets PowerShell apart? Notice that I do not mean, “what makes it better,” because “better” is something you’ll have to decide on your own. I just want to look at what makes it _different. _
