izs
blog.izs.me
Writing and Stuff from Isaac Z. Schlueter
521 posts
Don't wanna be here? Send us removal request.
Last Seen Blogs
krissteewartss
krissteewartss
chickencrosstheroad
Untitled
atd-sportscars-blog
ATD-Sportscars
clowntownunderground
"Beep Beep Richie"
Text
This full blog is now held at 2mblr.com/izs
ARCHIVE
You can view all my past posts and Follow me there!
5 notes
·
View notes
Text
wow
i love cutthroat kitchen but bingewatching makes it really stand out how often alton brown refers to himself as ‘daddy’ and makes contestants wear spreader bars
657K notes
·
View notes
Text
OSS, Risk, and Compliance
I’m going to tell you a story.
There are no villains in this story. Just smart people doing their best, and unfortunately working at cross-purposes through no fault of their own.
The names and places have been changed, but it is a true story. I’ve heard this story a lot over the years in my role at npm.
Once Upon A Time…
Way back in the late 1900s, the once-successful ACME Corporation was falling behind. Their development of proprietary widgets (on a proprietary software stack) was unable to keep up with the competition, who were leveraging Open Source platforms at a much lower cost.
Many within ACME Corp wanted to adopt the OSS approach, but they were bound by a multitude of contracts and agreements with customers and the regulatory rules of the various countries in which ACME Corp operated.
ACME Corp was in a pickle. Over a barrel. Pickled in a barrel of mixed metaphors, one could say.
Accepting Open Source Software
Luckily, ACME Corp hit on a solution. They joined some of the foundations springing up to provide governance structures for popular OSS projects, and instituted a policy where any employee could use any Open Source code that they liked, provided it was submitted for review by their compliance team.
This allowed them to avoid projects that were abandoned, insecure, or published with an incompatible license. Using a simple form was all it took, their developers could deliver value using the most up to date methods and tools.
Life was good.
Then Life Changed
Shortly after the turn of the 21st century, a series of well-intended solutions to valid problems ended up causing new problems for ACME Corp. All solutions, in solving a problem, reveal new ones.
First, GitHub made it far easier for developers of Open Source to collaborate with one another. This allowed projects to become quite popular without any corporate or nonprofit backing.
Next, Node.js brought JavaScript out of the web browser. Prior to Node, plenty of Server-Side JS platforms had been hacked up as side projects, or funded projects of promising companies. But Node was the first to significantly benefit from GitHub’s network effects.
The last piece of this puzzle was an early Node.js contributor, who’d been working in the SSJS space for a while, and decided to write a package manager. He’d seen the importance of package management as a development tool before, and had spent quite a bit of time thinking about how reducing friction makes great things happen.
Impacts
A simple module system and package methodology became ubiquitous. Suddenly JavaScript was easy to share and compose. Instead of JavaScript platforms having to include the kitchen sink, they could be lightweight toolkits with loose coupling between parts.
This reduction in friction enabled what came to be known as the “small modules” movement. A number of prolific Open Source enthusiasts began to conceive of a single file as the default unit of code sharing, instead of a branded platform backed by a foundation.
Meanwhile, back at ACME Corp…
With all this distributed sharing, instead of relying on 2 or 3 well-known OSS platforms with clear governance, web applications came to rely on an interconnected mesh of thousands of tiny modules, created by an unaffiliated horde of hundreds individual contributors.
At ACME Corp, the process has started to creak. Well, not “creak”, exactly. More like “break”. It’s broken.
The compliance team insists on only using modules that pass review. Developers who do write hand-rolled scripts to catalog all of their dependencies for the requisition forms are laughed at.
“2305 modules? You’ve gotta be kidding me. Use less, or come back next year.”
The best devs have moved on to companies with less stringent rules. New developers coming out of school don’t even know how to create websites without npm and React and Babel and a zillion of these things.
Today, the battle lines are drawn within ACME Corp, forcing developers to rely on subterfuge. The cost of a security vulnerability or getting sued for violating a license can be in the millions. But failing to ship a website is an existential threat.
When compliance complains that the new continuous delivery system is circumventing their OSS rules, the CTO says “I know, I’m on it”, and then quietly ignores it.
And they all lived happily ever after…?
I wish that this was pure fiction.
The approach to compliance in almost every industry has not kept up with the advances in Open Source Software practices. This is a pressing crisis facing some of the biggest software development teams in the world right now.
I believe this problem is solvable, but it is not adequately solved yet.
Most solutions ask an organization to choose between safety and efficiency; but inefficiency is never safe. The only valid approach is to reduce friction for development teams, while also helping compliance teams to do their job. This is the the only way to bring peace to the enterprise.
5 notes
·
View notes
Text
npm, Inc. has a new CEO, Bryan Bogensberger
Coming up as a software developer in Open Source, I’ve long believed that the best path to success is to depend on the strengths of others. One reason why I wrote a package manager in the first place was that I knew the JavaScript community as a whole could write a much better web platform than any one team or developer, if only we could reduce the friction in the collaboration process. I wanted that platform to exist, and frankly, had no idea it would turn out as wonderfully as it has.
When I founded npm, Inc. back in 2014, one piece of advice I got as a founding CEO of a startup was: start planning your transition (lest it be planned for you). I took that advice to heart, and throughout the life of this company, I have tried to avoid holding any illusions about my own abilities. After spending 8 years running npm – first as an independent project leader, then as a founding CEO – I learned my share of lessons about where my skills lie and where I fall short.
I have a passion for developing products that streamline the experience of creating software applications and sharing libraries. npm’s place in the development ecosystem speaks to some considerable skill in that area. I don’t have as much of a passion for running go to market efforts, hammering out the details of partnerships, business and HR operations, or managing a large team of employees.
These are interesting challenges, to be sure, and I adore this group of humans who have joined the company and added so much to npm. But it became increasingly clear that npm, Inc. needed new leadership if the company was going to make good on the promise of providing financial support for this cultural movement. I found that any attention I spent on anything other than product meant that the company suffered, and so did my soul.
It turns out hiring a CEO is hard! We spent 6 months on our first search, and the outcome was that the company was just not ready. Several extremely smart and capable people came in and said, “Yeah, you’ve probably got something here, but it’s not far enough along to hire someone like me.” So, we regrouped, reevaluated our strategy for our enterprise product line, acquired a security company, and came up with a better vision for the company’s future. Our second search had a much better result, with one candidate standing out, being both a good fit for the company and also eager to take on the challenges ahead.
Today, I’m happy to introduce Bryan Bogensberger as npm, Inc.’s CEO. He brings a wealth of experience in Open Source and a ton of excitement and expertise to help grow npm to the next level and beyond. Commercializing something like this without ruining it is no small task, and building the team to deliver on npm’s promise is a major undertaking. We’ve sketched out a business plan and strategy for the next year, and will be announcing some other key additions to the team in the coming months.
Meanwhile, I’ve taken on the title of Chief Product Officer and I will be spending my time focused on the part of the problem that I love.
I’m extremely excited about what 2019 will bring for npm, Inc. and the growing community we serve. If your company uses npm (spoiler alert: they do), and you’d like to see how you can professionalize your JavaScript story, check out npm Enterprise and npm Orgs. If you’d like to be a part of the company that’s continuing to improve how JavaScript is done around the world, come work here.
6 notes
·
View notes
Audio
(via Understanding Your Partner’s Attachment Style: An Interview with Stan Tatkin)
A great conversation about attachment styles. Awareness is power.
2 notes
·
View notes
Text
Brussels Sprouts
It's that time of year again, when a lot of people will enact great tragedies on that most underappreciated of vegetables, the Brussels sprout.
This is the correct way to prepare Brussels sprouts. It's also one of the easiest and lowest-effort. The ingredients are few and simple. The work is minimal. It requires very little skill and is easy to learn. If you've never had Brussels sprouts prepared like this, you'll be amazed at how good they taste. In fact, you may learn for the first time that they even have a taste, and that it is sweet and delicious, and not at all improved by bacon, cream, or vinegar, or whatever other awful tortures people put these things through.
Ingredients
Brussels sprouts, ideally all roughly the same size
Some salt
Plenty of oil
Steps
Rinse the sprouts.
Cut them in half longitudinally. That is, so that the cut goes through the stem, and you have two symmetrical halves. Don't cut them along the equator, if you do that they'll shred. Put them in a bowl and try not to break them up too much, but don't sweat it if a few leaves fall off.
Put enough oil in a large flat pan so that it covers the bottom. Heat it up.
While it's heating, place the sprouts in the oil flat side down. Don't just dump them all in there. This is important. Cover the bottom, but do not do more than one layer. Every sprout should have its flat face fully flush against the bottom of the pan.
If the sprouts start to absorb some of the oil, put some more in. The bottom should be covered, but they should not be swimming.
Toss any stray leaves in there just kinda randomly, it's fine.
Throw a bit of salt on them. I give it a good "shooka-shook" from the salt shaker, probably like a quarter teaspoon or so, but this is pretty flexible. Make them, and if they're not salty enough, put some more salt on them and use a bit more next time.
The cooking time and heat will need to vary based on the size of the sprouts. The goal is to burn the bottom and let the insides steam in the little dome of Brussels sprouts leaves. Big sprouts will take longer to cook the insides, so you'll use a lower heat and cook for longer. Little sprouts, turn that shit up (but if the oil starts smoking, that's too hot, back off a bit). If you get it a bit off, it's fine. Just means that they might have to get a little more or less browned.
They're done when the top is dark green and the bottom is completely browned (but not black, that's probably too much).
Use a tongs to pick one of them up and check if they're done. Other than that, do not fucking touch them. They don't need to be messed with, stirred, moved around, or touched. They just need to burn and steam, and that's it.
Results
They taste like sweet popcorn. I'm serious. The crunchy bottom tends to soften pretty quickly, so sooner you eat them, the better, but this is usually not a problem. (And they're still good when they're not super crispy, just a little less amazing.)
#brussels sprouts#correct recipes#please stop drowning your sprouts#no bacon no cream no seriously#i am not joking brussels sprouts actually taste good just stop abusing them
5 notes
·
View notes
Text
Node + JS Foundation
Today the Node.js and JS Foundations announced an intent to merge.
tl;dr – This is a good thing. I’m psyched.
The JavaScript community is a big and diverse group of people, doing lots of stuff. Most companies in the world use JavaScript, and at npm, we have a unique view into the shape and scope of this ecosystem.
The overwhelming majority of JavaScript users are people making websites, using modern frameworks, and tooling built in Node.js. They are trying to get a job done, and they want streamlined tools that make them more able to do their jobs. Many of them are not what we might have thought of as “Node Devs” a few years ago (though many are). Their websites run on every back-end platform, including but not limited to Node.js, and they all have to ship a website to browsers, which means JavaScript. Node.js is the dominant platform for building the tools for doing this, and npm is the place where platforms, modules, and tooling are distributed and shared.
A split between “back-end” and “front-end” JavaScript makes less and less sense in light of the way that this community has grown over the last 9 years since Node.js was released. (Wow, has it really been that long? Time flies.) A fast-growing community means that most of the people writing websites, using Node.js-powered tooling and pulling libraries and frameworks from npm, have only been doing it for less than 2 years. The split may have felt normal to those of us involved in 2009, but it seems unnatural and awkward to most working in the field today. It’s just JavaScript. It runs on servers, and on the command line, and in browsers, and you use npm and a bunch of other tools it provides. Is “babel” a front-end tool or a back-end tool? Why are there two groups, when it’s mostly the same people?
Node.js getting more integrated with the broader JS community means that the project can more effectively advocate for server-side use cases, and can get better feedback from those who are depending on Node.js to power the tools they use to ship websites.
As one of the companies at the center of JavaScript development, we at npm are thrilled to see the two major JavaScript foundations joining forces to provide a forum for the entire Open Source JavaScript community. Consistency of governance, processes, and policies can make it easier for devs in disparate JavaScript projects to collaborate and coordinate, removing an unnecessary barrier to innovation. Both foundations now have an established history of iterating on their processes. I hope that this new shift provides a chance to retrospect on what worked, what didn’t work, and what can be improved by working together.
On a personal note, I got involved with Node.js in the first place because I wanted to live in a world where front-end, back-end, tooling, and infrastructure coding did not require constantly shifting my brain around to a whole new language. I couldn’t have predicted how npm would become so relevant to the world of web development, and it’s more than I would have thought to hope for. There’s a lot of open questions about what exactly a merged foundation will look like, but I’m very happy to see things move in this direction.
11 notes
·
View notes
Text
Bookends
Content warning: suicide. I wrote this in January of 2014.
We don't often notice the difference between one day and the next in our memory. A year blends together. As you get more distance, a block of similar years become a single unit, characterized by a specific flavor of scenery, people, and feelings.
The cracks in the sidewalk that I'd avoid stepping on as I crossed the bridge over Fitch street on my way to class. The girl I smiled at walking over that bridge, and the months of passionate sex and breakups that smile unleashed. The cheap limitless terrible food at Conn Hall. The drudgery of debugging printers for professors so I could pay my rent. Winters where stepping the wrong way on a sheet of ice plunged me ankle deep into brown slush. The insufferable New Haven towing racket and incredible pizza.
And then, in a flash, the channel changes.
Suddenly it's palm trees and vacuum cleaners, then Yahoo! and JavaScript. A terrible marriage and a happy divorce. Then it flips again, to Joyent and Node and bart and biking. Speaking at conferences. Open source, buzzwords and business cards. My arrival as an internet personality. Marisa.
It's blatant in hindsight, but I usually don't see it coming. Some changes are complete and total, marking a brand new lifetime with each transition. I'm not sure I'm the same person as a few versions ago. Every line has been edited, every vision altered.
This most recent shift, though… I saw this one coming. Or at least, I saw one side of the book mark.
I prepared the transition to be as smooth as possible. I recruited allies, and trained a successor. Now was the time. I didn't know what exactly would be showing on the new channel, but I knew that a change was coming, and I wanted to make sure it'd be good. This idea of book marks was going to be my Pastry Box contribution. I had thought it all out.
I had no idea.
On Christmas eve, I sat in a thai restaurant with my friend. Luke, who makes jokes, and travels the world, and works on npm. By the end of 2013 we hung out about weekly or more, to eat and chat and laugh. We had met at Taco Conf a few years prior, where he told me that he wanted to move to Oakland to hang out with the Node people. He did that. We clicked well. He watched my cats once. I recommended him to Yahoo.
The day before that dinner, Luke had written a note. We complained about the holidays a bit, and shared Kao Nam Tod. It didn't seem weird to me that he was in town. After all, I was also. I knew he was from upstate New York, but he didn't ever talk about his family there. I don't know if I ever talked about my family much either. Just never came up. We reminisced about New England winters and how much nicer California is. We talked about how horrible the holidays are, and about business and dating and the future.
A few days later, I went out of town to visit family. The trip was too long by a day. At the end we were all eager to get back to our lives. I came back on New Year's Eve. I sent Luke a message the next morning, telling him that relatives had given me some cat toys, because they don't know how fat and lazy my cats are. Maybe his kitten could attack them, instead of attacking his face, like it usually did.
It was still early. I figured he'd get it when he got up. I could bring them by. I was working on npm that day. The new startup. The Book Mark. Everything was going great. I was looking forward to telling him about the latest developments.
I got a message from Luke at 4:15 in the afternoon. Before seeing what it said, it reminded me that I hadn't had lunch yet, and hadn't seen him in a week, which was a perfect coincidence. I was going to suggest Xolos. His message asked, "Could you share this publicly or privately in a few hours or so?" A link to the note that he wrote on Christmas Eve Eve.
Oh no. Wait. Where are you, I'm going there now. I'm coming to your house. 911. Call Mikeal. Call Dustin. Tell Marisa to bring the car back home, we have to go, now.
We met the police at his apartment. The key was where he said it'd be, and there was food and water for his kitten. Calling, again and again, it rings 4 times, and then voicemail. iMessages delivered, but no response.
5:09, another buzz in my pocket. "I've finally built up the courage to do it. Thanks again."
Calling. Straight to voicemail.
He said he'd been hiding for years, that he was tired of pretending, tired of masking his pain. It wasn't a statement, it was a choice, an expedient escape from his medical problem.
We didn't know where he went. Searched everything, everywhere. Yahoo hired an investigator. The police were beyond useless. Clues pointed to a bridge, most likely the Golden Gate. Coast Guard didn't have any John Does.
He slipped through my fingers like smoke. He'd reached out to me. I didn't save him.
That week, I learned a lot about Luke's history, things he never told any of us. I learned about his family, his past, his friends. I talked to his mother and sisters. Eyeballs deep in other people's shit, the unexpected executor of my friend's farewell. I frantically invaded his privacy, tried to find anything that could give me some hope, some clue, some rock I could turn over that he'd pop out from under.
For a while some hoped that he was faking. He'd fled to Asia or Africa on some manic adventure, played a joke on all of us. At 5:09 on New Year's Day, I lost my hope. He wasn't joking. Luke's jokes are funny, and clever, and often offensive. His note was calm, resigned, touching. If he had been crying for help, we would've been able to help him. He was smart. He knew what he was doing. He was doing it for himself, not for anyone else.
I waited for permission to grieve. I told everyone else that we can't give up hope until they find a body. But that was a lie, and I wasn't fooled. I passed along the flyers, in a gesture of mourning.
In December, I'd hoped that this phase shift would be marked by the change of job roles, and in the fullness of time, maybe it will be. But overlaid on that is the turbulent border between the part of my life where my friend Luke existed, and the part where he was abruptly and permanently gone.
4 notes
·
View notes
Text
npm Pride 2018 Shirts
npm loves everyone!
Just like last year, npm team’s Pride shirts available to all, with help from our friends at &yet and Teespring. Select your favorite design from the pictures below and click through for types and sizes — or collect them all! — and 100% of proceeds will benefit The Trevor Project.
Heads up! The timer on each Teespring page resets every three days when an order goes out — these shirts will be available indefinitely.
Are we missing a design? Reach out and let us know!
14 notes
·
View notes
Text
npm Acquires ^Lift Security and Node Security Platform
Today, we’re excited to announce that npm, Inc. has acquired the team and assets of ^Lift Security, including their work on the Node Security Platform. Adam Baldwin and his team have joined npm to work full time on keeping the npm Registry and npm applications safe, and to develop new products to help developers and their companies securely develop JavaScript.
We go way back
^Lift Security has been working with npm longer than npm, Inc. has been a company. They review npm’s own code to ensure it’s safe before we take it live, and conduct periodic security audits, including penetration tests of our services. Most prominently, their Node Security Platform has become a definitive catalogue of JavaScript vulnerabilities for developers and security vendors.
npm is where the Node Security Platform belongs. All NSP users are npm users, and the security of open source code is core to npm’s mission. By combining our resources, we can deliver a continuous approach to security at scale, empowering millions of developers to build more secure code.
As one team, we’ll continue keeping the Registry safe, and develop new ways to help individuals and companies understand and trust the JavaScript code that they write and share.
Watch this space
Today’s announcement is the first in a series of strategic security initiatives we’ll be announcing in coming weeks. In conjunction with the next version of npm, shipping with Node.js version 10, we’ll introduce a series of new security features available to every npm user, directly integrated into the npmjs.com registry and the npm command line tool. Soon, we’ll also introduce a series of security products specifically tailored to the unique requirements of corporate developers and enterprises.
Security is everyone’s responsibility (including yours).
Security is the responsibility of every part of an organization. It needs to be intermixed with engineering, operations, and application development. npm is at the center of these workflows, so we are uniquely positioned to help you secure your code.
We know that the safety of the code you use is important to you, whether you’re a beginner or a seasoned expert. Together, we’ll ensure that the world’s largest community of software developers is also its safest.
4 notes
·
View notes
Video
Bundt Lasagna. Yes. This is brilliant. I need to do this.
instagram
https://www.instagram.com/p/Bgiyx_ohoX7/?taken-by=tastemade_japan
812 notes
·
View notes
Text
Protect your npm account with two-factor authentication and read-only tokens
UPDATE: To try out TFA, you’ll need the beta of the npm client. To get it, run `npm install npm@next -g`.
Today, we are announcing two new ways to protect your npm account. Please read on to learn how you can use these security features to keep your code safe and increase everyone’s trust in the more than 550,000 packages of code in the npm Registry.
Two-factor authentication (2FA)
Now, you can sync your npm account with an authentication application like Google Authenticator or Authy. When you log in, you’ll be prompted for a single-use numeric code generated by the app.
2FA is another layer of defense for your account, preventing third parties from altering your code even if they steal or guess your credentials. This is one of the easiest and most important ways to ensure that only you can access to your npm account.
Read-only tokens
If your continuous integration / continuous deployment (CI/CD) workflow includes linking your npm account to tools like Travis CI with authentication tokens, you can now create read-only tokens for tools that don’t need to publish. You can also restrict tokens to work from only specified ranges of IP addresses.
Even if your token is compromised — for example, if you accidentally commit it to GitHub — no one else can alter your code, and only authorized CI servers will be able to download your code.
Set these up now (please)
The npm community is now larger than the population of New York City, so it’s never been more important to reinforce trust and encourage collaboration. Every developer who secures their npm account with these new methods helps ensure the safety and integrity of the code we all discover, share, and reuse to build amazing things.
Learn how to activate 2FA in this doc:
Using Two-Factor Authentication
Watch this space
There has never been a major security incident caused by leaked npm credentials, but our security work is never finished. We work continuously to protect the npm Registry and detect and remove malicious code, and we try to keep you informed of our efforts.
If you ever believe you’ve encountered any malicious code on the Registry or in npm itself, contact us right away [using the npm website](lgt security contact form) or by emailing [email protected]. If you have any feedback or questions about what we’ve rolled out today, just contact [email protected].
Thanks for helping keep the npm community safe.
7 notes
·
View notes