davidkhess

Thanks for mentioning LSD. I had not seen that yet.

> Well, that is for one simply completely impractical, those people are few compared to the amount of software the world needs and also very expensive. But it's only one of many reasons why there are better approaches so let's move on.

How many years of expertise do you think architects of large buildings probably have? Engineers of critical bridges and other public infrastructure? One thing we need to do is stop aging out our best talent.

> Many detailed requirements have, as matter of fact, been very visual, with detailed user interface mockups, process diagrams etc. When they are large in scope, they have been found not to be useful compared to the effort required to create them. When they are small in scope, they are actually used in real world agile software projects.

> And, I have to ask something about this process where extremely experienced people create detailed visual blueprints for the entire scope of the project and then deviate very little from it. Is it something you've actually seen produce good results (repeatedly) for your run-of-the-mill software projects?

Absolutely. I have a 100% success rate using these techniques with over 20 under my belt. Granted, I'm mainly a solo operator but I've used it for larger projects too on occasion.

> Well, every time you give concrete proposal about what to do in the face of uncertainty it sounds exactly like agile.

The difference is time frame and phasing. Consider deciding to enlarge a kitchen in the middle of building a custom house. Now compare that to an addition to an existing home. They are very different situations.

> That would, again, be agile. And I say that as someone who is not even particularly fond of of most standardized agile processes, such as scrum.

The difference again is the time frame and the phasing. Messing with the scope/design every week I think is an anti-pattern and a contributor to project failure.

The only part of the agile approach I like is iterative delivery.

First, I believe software blueprints should be put together by people with 15 to 30 years of expertise. Secondly, blueprints for a custom home are completely indispensable and are referred to regularly during construction. I believe one of the reasons why is because they are visual, not textual. I believe software requirements should be the same and then they would be easier to adjust and would retain their value.

Custom homes can be adjusted in mid-build. But it is a big deal and you have to get the architect involved and potentially have your plans revetted by inspectors and the city. It's a process that has a high cost. And it should because good blueprints like good software designs are highly dependent internally. I believe every change risks degrading their quality.

If you are in a project where there are large numbers of unknowns about the functionality of the project, I highly recommend shrinking the scope to what you know and actually understand. Build that, and then learn from it. Then come back around and start a new "dave's custom home waterfall" (for lack of a better name) process to implement the next set of functionality.

Constantly course correcting is a recipe for never finishing and weakening quality. There should be natural impediments to course correction and scope reduction should be used until the unknowns have been reduced to a reasonable risk level.

Very nice. Thanks for the pointer!

To the first concern - that’s why I recommend you deliver (ideally) weekly intermediate builds of the product to the end user. Typically an underlying issue will begin to surface pretty rapidly.

To the second concern, first, let’s get on the same page. When I use the home analogy it’s in regards to a custom home - not a from-plan/spec home. To your point, I believe well developed software should also have strong and obvious patterns that are reused in many if not all other projects.

I don’t think developing a solid and complete blueprint at the beginning of the process qualifies as agile.

In other words, waterfall didn't go far enough. Instead of discarding it, we should have continued to improve it.

Partially. But I think waterfall has (at least) two major weaknesses.

The requirements are textual. They should be visual like a blueprint.

A real custom home is typically visited and inspected regularly by the future home owner during construction. An improvement for waterfall would be a periodic delivery to the user of intermediate builds of the product – no matter how incomplete.

I'll never understand why the software development community as a whole seems to have such an NIH attitude to software project management. Meaning, why aren't our people studying what works in other industries and figuring out how to apply it to our industry?

Is it some conceit that software development is somehow truly unique compared to the problems and concerns faced by other industries? That's dumbfounding to me if so.

Our industry is barely 70 years old and hardly anybody seems interested in stealing the best ideas and practices from other industries that in some cases have been around for thousands of years.

On a comment to the article:

> To give an example, the app I’m working on (https://github.com/OSSIA/score) is roughly 300kloc of Qt / C++ code and compiled in WASM almost from the first try. I’m still having freezes in some places but overall it’s working great.

It definitely can get messy, but there are some very easy ways to keep your project well structured.

1. Refactor out to separate components a lot.

2. Use the .ui.qml and .qml code behind pattern to separate UI from code.

3. Use singleton QtObjects to create abstract classes that contain any non-UX behavior.

As for graphing, the built in components work pretty well:

https://doc.qt.io/qt-5.10/qtcharts-index.html

As far as QML widgets go, they have improved greatly since they released Quick Controls 2 (a rewrite of the initial set of controls).

https://doc.qt.io/qt-5.10/qtquickcontrols2-index.html

And for those interested, here's a link to the paper: https://fc18.ifca.ai/preproceedings/6.pdf

It seems like this is a pretty important and existential issue. If illegal content is injected into the blockchain, how do you remove it without a hard fork? Immutability is the whole point, right?

I'm a fan of QML and use it regularly to build cross-platform mobile apps – however, how would this fair any better than Flash or Silverlight did?

It seems like there needs to be some strategy for how this would roll out to market and feasibly gather market share before I could take the concept seriously.

Unless you actually set the address bar (i.e. window.location) to localhost:25519 I don't think this is going to work. I've used ajax with REST APIs that return 302s and you will receive the body of the destination page as the return value to the ajax call. The page in the window (window.location) is not going to change. And this is of course if localhost:25519 returns the proper CORS headers in the first place to allow the ajax GET to even occur.

I think the only way this could work is if you set the window.location to localhost:25519 when starting the SQRL authentication. That will result in harder UX problems to solve but it does seem feasible.

Regardless, having reviewed FIDO and the W3C Web Authentication API, it seems to me that SQRL doesn't have a chance of seeing any wide adoption once those two are available. They have the dual advantage of standardization and platform control that are nearly impossible to overcome by external offerings.

It seems like this would require native browser support because if it were done in Javascript, couldn't the MITM be able to take the redirect response and send it on to their backend?

If it does require native browser support, I would worry about chicken and egg adoption issues.

Can you expand on what "Client Provided Session" means?

To me, the fatal flaw in SQRL (and options like it) has been MITM (man in the middle) attacks. For instance:

https://security.stackexchange.com/a/46205

Hhhmmm. According to DNS, I'm talking straight at a Cloudflare IP and getting a redirect to adware when trying to load Vue.

Evidence here: https://pastebin.com/wVCABkaA

Seeing the same thing when trying to load Vue.

Tweet from them:

https://twitter.com/unpkg/status/852655106562564098

> We're experiencing some issues and working on it. Will post updates here as soon as we know more.

I completely agree with his sentiment. While it certainly won't catch all vulnerabilities, it should at least catch the more obvious and easily exploitable ones. And it concentrates the skills required in an entity that has a business model that can sustain it.

I see it as analogous to FCC certification of RF related equipment.

There used to be a thread in the Firebase Google group about this which is gone now. It still lives on here:

http://grokbase.com/t/gg/firebase-talk/154mr25k86/firebase-m...

That thread is not encouraging.

Edit - found the original thread here:

https://groups.google.com/forum/#!topic/firebase-talk/LjHATl...

The concern I've always had with Firebase is the lack of a business logic layer between clients and the database. This tends to force the business logic into the clients themselves.

Trying to change the schema if you have Firebase clients deployed that can't be instantly upgraded via a browser refresh (i.e. iOS and Android mobile apps) seems an extremely challenging task.

Seems telling that Facebook chose to shut it down rather than spin it back out on its own or sell it. That implies the economics of it weren't working.

I'm the author of the article (and the 2 parts that follow). I'm attempting to draw attention to the weakness of existing web app architecture and proposing a (hopefully) better alternative.

Happy to answer questions and discuss.

If you use `codesign -v --verbose /Applications/Xcode.app` you may see:

  file added: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man/whatis
  file added: /Applications/Xcode.app/Contents/Developer/usr/share/man/whatis

That should be safe.

It's a bit of a shock that Apple:

1) is modifying sealed containers post-install (it's the weekly periodic job that rebuilds whatis database from installed man pages)

2) doesn't realize this and has put out instructions that will cause lots of false positives

My perspective having developed with Python for over 20 years now: it depends on the nature and context of the problem being solved.

In my experience, you usually need a CPU intensive problem for the implementation language to be a speed concern. Many practical everyday problems solved with Python (outside of contests and specialized fields) tend to be I/O bound.

Secondly, even when you do have a CPU bound problem, many Python modules you might use to solve it are wrappers for C/C++ implementations.

As a result, I've come to think of Python as a control and integration language and less as a platform for base algorithm implementation.

Viewed that way, I've found Python to be unbeatable for speed of implementation and long-term maintainability (two of my top metrics for valuing code).

Re: shared device use, yes, you would continue to do password management best practices (fingerprint scans, master passwords, etc.).

I see the transferability as an export/import format issue. W3C, browser vendors and password managers need to agree on a format for keychain export/import.

Note that this technique could still be used in conjunction with multi-factor auth. Since it is just an evolution of passwords, those type of mechanisms are still relevant and compatible (though, eliminating knowledge factors should reduce need for a second factor).

If the W3C and the major browser vendors could agree to the API and Keychain specifics, it would help a lot.

So far, both the W3C and the browser vendors have been AWOL for the most part on real solutions to this problem.

If you are interested, I'm looking for folks to help flesh it out and promote it. Any and all help is welcome!

Ah, so the expiration issue is smaller than I thought. Thanks for that info. Still, it represents a training issue for users and a new framework to be incorporated into a web app. Those are both barriers to wider adoption.

I agree the security of this solution may be right for certain applications.

Yes, my proposal is an infrastructure play - but I believe it is a more realistically achievable one than most password alternatives.