michaelw

Similar to LinkedIn's "verified" process, Porkbun uses a 3rd party: veriff.com. https://www.veriff.com/privacy-notice.

It appears that Veriff's data retention is set by their customers (in this case Porkbun). Porkbun's policy says that this information is deleted as soon as they have verified that you "pass." They aren't quite as explicit as saying that they require Veriff to delete it that quickly.

Unfortunately there's a giant loophole in Veriff's policies (emphasis mine):

  (5) Fifth, we store Personal Data only for as long as the retention of data is required by law, a contract *or is necessary for the provision or development of our Services or required for protecting us against legal claims.* At the end of the retention period, we shall permanently erase the Personal Data or anonymize it.

From Hyrum's Law to AI generated unit tests to automatically validate implicit dependency contracts.

Oh this brings back some fun memories. I worked with QNX for the ICON computer at Cemcorp and ESP Educational Software Products.

The OS was so clean but it lacked a lot of basic tooling. Back then there was no GUI or even a graphics library. We had to build or port a lot of things, including a VCS, from scratch. My editor of choice was JOVE (I couldn't get Emacs to build). I remember digging up various papers on graphics and creating our first graphics library.

Please see my other reply about network costs. Bandwidth is a real cost that does not currently show up on the balance sheet because of Fastly's generous donations.

That said, I would love to see more organizations implement private staging repositories for their upstream package supply. This is where they can and should apply policies to protect their applications.

Developing a single multi-protocol or even multiple open source caching proxies will cost real time and money. I'd love to see more solutions here but at this stage it will take more than a few volunteers and a "PRs welcome" in the README.

If the costs were all bandwidth related I would agree. Most open source package managers benefit from Fastly's generous donation of credits. Even if one ignores the single-provider-point-of-failure risk, the reality is that the development and operational costs of running package managers is much more than just networking bandwidth and more is needed.

Malware scanning, AI slopsquatting, and typosquatting are just a few of the things that package managers do today. Implementing emerging standards like Trusted Publishing ( https://repos.openssf.org/trusted-publishers-for-all-package... ), the Principles for Package Repository Security ( https://repos.openssf.org/principles-for-package-repository-... ), and improved infrastructure hardening will all important.

The key insight is that these are services that require development and operations budgets that scale with their usage.

Original joint statement on the OpenSSF blog: https://openssf.org/blog/2025/09/23/open-infrastructure-is-n...

Package managers are the app stores of software development. They are essential to the developer workflow and are key points of leverage with regard to supply chain security. They will be even more critical as AI-based development expands.

The root-cause problem is that package managers are funded like charities when they should be operating like non-profits. Their costs scale with usage but their donation-based revenue is dwindling. This problem has been partially masked by generous infrastructure donations but the operational costs are not just network and compute. There's a lot of security engineering development and ops in running a package manager service.

Host your own dependencies folks!

There are three major types of risk in software supply chain:

  - Correctness. Does the source have flaws (or backdoors) that allow it to be exploited.
  - Integrity. Was it tampered with from source to binary (typically to inject intentional flaws or backdoors)
  - Availability. Is it available for use in a build. 

There are all kinds of nasty examples of dependencies going away. The two big patterns are:

  - Infrastructure availability. That's this case and yes, CDNs are a nasty point of failure. Wanna guess how many package managers depend on a single CDN?
  - Intentional delisting. This has happened often enough over the past few years. When the package maintainer throws their toys out of the pram and either removes the package from public access or effectively zeros it out. This can happen to the source too (hello colors.js)

I'd like to see the major cloud providers caching all the major package repos inside their networks.

I'd also like to see multiple CDNs for every major package ecosystem.

I highly recommend reading https://slsa.dev

Here's a simple way to think about fuzzing. If you're not fuzzing your interface to find vulnerabilities, someone else is.

I didn't see anything about the many benefits that are not typically considered income by the IRS. Most notably, health insurance represents a significant extra cost that makes that 18% advantage look a little smaller. Add in 401K retirement matching and factor in the increased risk and the advantage probably goes away.

This is simply not true. In fact, working at Google will expose you to all kinds of interesting ideas and problems. Many of those problems will just sit there because Google can't prioritize them right now.

Let's count all the reasons not to leave:

1) If you don't have an amazing idea now, leaving won't make it easier. If anything it will be worse since you won't be constantly exposed to real-life problems.

2) Building great product is about a lot more than ideas. It's about execution, timing, scaling and a ton of luck.

3) After only two years at Google you're probably an L3 or L4 engineer. You have much to learn. Seriously. It probably took you a year to become productive so you've only scratched the surface. Go find a senior mentor and get them to talk about their journey. You'll be surprised.

4) Startups are hard. Don't believe the hype. Your startup will fail you. Even if the startup succeeds, you personally are unlikely to hit a payday. Remember the Golden Rule: Those who have the gold make the rules. The most likely outcome from any startup is that it fails. The second most likely outcome is that it fizzles and gets bought. Your equity would turn into a diluted options over 4 years.

5) In another 3 years at Google you'll save so much money that you'll have an entirely different set of financial options

6) Your long term career impact and financial success will actually be better off if you find a way to apply your ideas and passions within Google.

7) You are currently surrounded by some of the smartest software people in the world working on some of the hardest problems.

8) Look for a transfer to one of Google's SE Asian offices. Lots of interesting projects there.

To be blunt, it sounds like you're finding out that working as a software engineer is, well, work. It is. That doesn't mean you can't find your passion in what you do.

Buy yourself your own computer and work on your dreams at home while receiving the engineering and execution experience of your lifetime. Actively seek to learn more about your craft from a company that is still writing the book on this. Take advantage of internal instruction opportunities to expand your skillset (where else will you get paid to learn about ML from some of the best). Once you've earned your stripes at Google you'll be able to work anywhere on a just about anything. You'll also find that you actually understand the realities of product development and software engineering in ways you do not today.

I started working at Microsoft in the late 80s. I'm now at Google as a PM. I've done a bunch of startups and consulting along the way. My career has spanned over 30 years and there's no doubt in my mind that it was the time at Microsoft that gave me experience, skills and opportunities I would never have had elsewhere.

If your heart is set on the romance of startups, go find it. You'll learn a lot there too. Just don't do it because you're bored of work.

PM me if you want an extended version of this with Google insider specifics.

You can do some pretty cool stuff when you're an MVNO. No need for custom dialers (which wouldn't be much fun on iOS anyways).

The system uses inbound calls, calling history and contacts to learn how to handle outbound call. User preferences control the defaults.

Get a call from Fred on the first number, all calls to Fred will use that number. Make a call to Mary with the second number, future calls to Mary will use the second number.

Throw in multiple sets of contacts from your work and personal email accounts and it's going to be pretty smooth.

Full disclosure: the co-founder is a friend. I have no involvement in Mast though.

A white label uber like app for use by municipal taxi authorities.

There's no need to throw the baby (taxi regulation) out with the bath water (getting a taxi is usually inconvenient).

The author of this article is http://en.wikipedia.org/wiki/Bob_Kohn

  "Bob Kohn is the founder, Chairman and CEO of RoyaltyShare, Inc., an outsourced royalty processing solution for the music, book publishing, brand licensing, and motion picture industries."

  "Bob is the co-inventor on a patent covering a web-based royalty system and user interface."

I'm not saying he's wrong but it's disingenuous not to mention that in the blurb at the end of the article. Instead he's described as a lawyer and author.

A good move by Fluke. The Fluke product retails for 10x the price but it's still a nice gesture.

http://en.wikipedia.org/wiki/Full_disclosure_(mailing_list)

  Full disclosure is a lightly moderated security mailing 
  list generally used for discussion about information
  security and disclosure of vulnerabilities. The list 
  was created on 9 July 2002 by Len Rose and is 
  administered by John Cartwright.

Take a look at flexbox. http://css-tricks.com/snippets/css/a-guide-to-flexbox/

While I agree with what SICP says, the function in this case isn't really a function. It's not something a caller will ever invoke explicitly. It exists to provide a closure that can be initialized with the injected parameters.

Pretend for a moment that Javascript had macros (sweet.js where are you?) and the Angular syntax was more explicit:

  myModule.provider ProviderName
  inject $scope, $document, SomeOtherDependency
  {
    your code here
  }

Javascript's greatest weakness is that it's native syntax is poorly suited for creating language like extensions. The result is that things like modules, imports, etc. tend to be very verbose and noisy.

This has less to do with Angular and more to do with Javascript's general inability to express a useful DSL for anything.

I think your ad hominem and somewhat hyperbolic complaint would be more credible if you supplied more concrete examples of how Angular caused your product to be two months late. I'm not saying you're wrong. I'm just saying that nothing in your comment actually makes your point.

My team has made very effective use of Angular and far from making us late it has saved us considerable time.

We treat Angular not as an abstraction or framework but as a toolkit for doing the following:

  * Extending the browser's built-in HTML and CSS with our own custom behaviour.

  * Two way databinding between our application data and the DOM

  * Architecting small testable / mockable components

There are two things I know to be true about humans.

1- Humans think they are good at risk assessment 2- Humans are very bad at risk assessment

In particular, humans suck at dealing with very big or very small numbers.

Let's look at DSLs that which they were DSLs. To be kind we'll limit ourselves to javascript.

On the building side we have Grunt and the less popular but still useful Jake.

Ember's property system is a DSL.

Angular's DI syntax is a DSL and as much as I love Angular there's really nothing to like about the horrible mix of ([{ that one has to use here.

Actually Ember and Angular and just about every meaningful javascript framework defines several small DSLs.

Pencil Code is an excellent learn-to-program DSL built on Iced Coffeescript.

Coffeescript's crazy syntax makes DSLs slightly more approachable than Javascript but only for a while.

Express and most server frameworks define a DSL.

Anytime you find yourself passing a non trivial config struct you're really playing with a DSL.

This is by no means a complete list.

I like these questions but they feel like a review of "Javascript: The Good Parts." Still, there's no doubt that someone who does well with these questions is going to have excellent javascript-fu.

My first concern when hiring front-end engineers is the engineering part. It's just too easy for a front-end dev to have excellent javascript knowledge and still create intolerable code.

I'll actually be doing an interview in two days so I'll give the above a whirl and see.

Waze uses Bing maps on the backend.

Wanna bet that "look forward to working with them in our ongoing effort to make a comprehensive, accurate and useful map of the world." means converting to use Google maps?

I use http://plnkr.co and apart from the outrageous amounts of memory it can consume it's pretty good.

Features I like about Plunker: - Multiple files - Great code editor (ACE) - Streaming collaboration mode (so others can follow along) - Versioning

Features I want: - Test endpoints (echo and/or redirect to a resource would be fine) - Github integration: able to save and load assets to and from github - Add Javascript librarie references from CDN (jsbin does this best) - Unit test support (some do this but it could be better) - Easily self-hosted for use on an offline laptop - Mobile previews - Better search (find me all the fiddles/plunks that include calls to angular.extend)

OK, I want these things to turn into lightweight IDEs and REPLs.

Sigh.

What I wrote about the Google i/o fail applies just fine here. http://www.michaelw.net/google-io-fail/

This is a classic case of optimizing the wrong problem.

The notion of first-come first-served makes almost no sense in an oversubscribed internet queue. It’s one thing to serve the first person standing in line outside a store, it’s another thing to pretend that this is meaningful when the queue is 100,000 people around the world all of whom were all in line at 10:00:00am.

It would have been more fair, less annoying and generally less embarrassing to formally recognize that this is effectively a random lottery. As such, have everyone pre-register over a period of days or weeks and then on the magic day, randomly select winners.

My rant appeared to help. I received an invite a month later.

$routeProvider and $location are special in that can be injected into .config. It may be that they are actually implemented as special constants. I do not believe that non constant providers can be injected.

Do you have a fiddle or plunk that shows this working?

The benefit of the different types of providers comes in how and when they are used.

Constants are especially interesting because they can be injected into the .config function of a module. No other provider can be injected for the very good reason that .config cannot inject transitive dependencies. Because constants cannot have any dependencies (unlike services and factories) and do not change (unlike values) they are safe to inject during the config phase. FYI, the .run function is invoked (and its dependencies injected of course) after all modules have finished loading and all config functions have been run. If your provider needs another provider as part of its init then you can set that up in the .run function.

Remember that DI in angular is not magic. It is quite literally the creation of a closure whereby angular invokes your provider function with your dependencies passed as arguments.

The difference between factories and services has a lot to do with how they will get used and singularity of them.

I think the mistake of the documentation is that it leads the reader down the path of the convenience functions first rather than instilling a deeper understanding of the core DI mechanism.

As always with Angular docs, they are dense and it always pays off to understand what you are reading as deeply as possible. Use the force, read the source.

I'd add a few more thoughts.

Keep your controllers lean and mean. Put more of the UI logic into services. This makes testing a lot easier.

Only use routing ($route, $routeProvider) if your app has very little UI state and could reasonably thought of as several totally independent pages. I switched to managing $location.path() explicitly and haven't looked back.

Embrace promises throughout your app. Angular templates can now render promises naturally but I've found that I prefer to be more explicit:

  $http.get(url).then(function(response) {
    $scope.something = response.data;
  }, function(error) {
    $scope.$emit('error', error);
  });

The Angular Bootstrap project is trying to create directives that avoid jquery and could be bound (with different templates) to other UI frameworks. What I really want is a core set of UI widget directives and then separate (bootstrap or foundation inspired or not) CSS libraries for styling them.

This page http://docs.angularjs.org/guide/di is a good starting point.

Angular makes extensive use of dependency injection. The unit of DI in Angular is called a provider. A provider is a function that can be injected and takes it's dependencies as arguments. The function then performs a provider role specific action when invoked.

The specific problem here is when the developer relies on Angular to infer dependencies. Angular does this by converting a function reference to a string which returns the full source of the function. It then parses the function parameter names and resolves those as dependencies.

The canonical example of this is an Angular controller (which is one of the provider roles).

  someModule.controller('ControllerName', function($scope, $http) {
    $http.get('/something').
      success(function(response) {
        $scope.someProperty = response.data;
      };
  });

  someModule.controller('ControllerName', function(a, b) {
    b.get('/something').
      success(function(c) {
        a.someProperty = c.data;
      };
  });

As I mentioned elsewhere, everywhere Angular takes a function as a provider it also takes an array. The array is expected to be a list of dependency named and a function. I've found that the DRYest way to declare a provider is like this:

  someModule.controller('ControllerName', ['$scope', '$http', function($scope, $http) {
    $http.get('/something').
      success(function(response) {
        $scope.someProperty = response.data;
      };
   }]);

  someModule.controller('ControllerName', ['$scope', '$http', function(a, b) {
    b.get('/something').
      success(function(c) {
        a.someProperty = c.data;
      };
   }]);

Probably a longer answer than you were expecting but I hope it helps. :)