1. 20

    I’ve recently been moved to a Django shop and I definitely miss the sense of “It doesn’t do much more than that.” Django seems like a wizard that you only interact with through a tin-can phone. You trust because you see things happens and because everyone else also talks to the same wizard, but you can’t help but feel a fool.

    While the boilerplate-y nature that I stumble upon in many Flask projects is something I don’t like, nor as the the author mentioned, configuration, I do appreciate the grounds-up approach, the you know exactly what’s going on because you wrote it. That sense of ownership I don’t feel with Django projects.

    1. 10

      While the boilerplate-y nature that I stumble upon in many Flask projects

      I’ve come to see boilerplate as a side-effect of being explicit. I see the same argument made for/against Redux (the JavaScript state management library) and its surrounding ecosystem. I too don’t like boilerplate but 9 times out of 10 I’ll happily trade a lot of boilerplate for being explicit about what’s going on (and often static analysis).

      1. 6

        I felt like that about Django for the first year or two, but it went away once I’d spent enough time spelunking the Django code. None of it is magic, but there is a lot of it.

        1. 2

          This has been a common complaint about Django for many years, so I made mini-django[0]because I too started to enjoy Flask’s simplicity, but every. single. time. my Flask projects bloated in to a frankenstein of semi-supported apps with little consistency between them. Now I can have a single file Django “function” that can use as much or little of Django as needed. Just look at the source of mini-django/mini_django.py.

          [0] https://github.com/readevalprint/mini-django

          1. 1

            http://padrinorb.com/ tries to be a django-inspired framework built out of flask-like components (sinatra). I used to be involved in it and really liked that it had a story of growth. You would start with a one-line project and could evolve it along into new and new structures until it could look similar to the size of a Rails project, which I find appropriate for huge projects. I agree with you that following along with that story gives you a ton of ownership into the project. You know why each component is there, because you chose it.

            The disadvantage is that there’s another ton of work to do on the project side to explain that philosophy, why it’s worth it and how and when people should move along that story. It needed a lot of resources to maintain that.

          1. 4

            I would be less sad if Microsoft had chosen Gecko/Servo here but I’m not too sad all the same. I don’t (yet) understand what rendering engine/JavaScript VM diversity really gave web developers. I can get behind browser diversity but it seems like what’s beneath the surface doesn’t matter anymore. I’d point to iOS as an example of this—Safari vs. Chrome is a worthwhile debate but it’s all WKWebView under the hood, and because of that iOS users can all benefit from the performance/battery life and site compatibility.

            1. 4

              What plurality amongst engines gives is an insurance that the web will be developed against actual standardized behavior rather than just the implemented version of the majority engine.

              There are lots of examples of eg. optimizations that assume that all browsers work like browsers with a WebKit origin does, but such optimization may not at all help in eg. Gecko or even make it worse there.

              1. 2

                There are 2 ways to address this: having even more browsers with substantial marketshare or having just one open source rendering engine that is used by all.

              2. 2

                And all sites running anywhere on iOS as a consequence suffer from WebKit’s poor and generally laggard support for newer standards.

              1. 10

                So it was true – Edge will move to Chromium and the web will have yet another major browsers that have WebKit origins – a sad day for the web.

                Now only Gecko/Servo remains as alternatives of other origins.

                Things I haven’t yet understood:

                Will Microsoft also use V8 rather than Chakra? And if so, will they as a consequence also drop official development on Chakra and on the Chakra-based Node.js?

                1. 5

                  There’s now one less closed source browser, I’m not sure how that’s a sad day for the web? If anything the web is more open since all major browser engines (Blink, WebKit, and Gecko) are open source projects and take outside contributions.

                  1. 12

                    Plurality is losing, open implementations are gaining. The open web standards are hurt by a lack of plurality, so even if it’s a win from an implementation perspective, it’s a loss from a standards perspective - and I would say that the loss in the standards perspective outweigh the win of the implementation perspective in this case, in an open web regard.

                    1. 5

                      If you wanted to write your own browser, you might try implementing various standards. However, your success depends on whether other people follow those standards as well. If there are many implementations, even proprietary, then people will make web pages that aim towards the center. If there is only one, then standards won’t matter.

                      1. 1

                        To be fair though, the amount of effort required to write a useful browser from scratch in 2018 is so insanely high than even a corporate behemoth like Microsoft with $$$ oozing out of its ears can’t stomach it. Is that really a use-case worth addressing? Would we really be worse off if there was just a single open source engine that everybody used? Kinda like Linux has become the universal kernel for running native binaries in the cloud…

                        1. 4

                          This problem only worsens when the corporate behemoths consolidate. What are the chances that MS pushes back on a new feature that’s too complex now that they don’t have to implement either?

                          1. 1

                            Complex for browser developers or web developers?

                        2. 1

                          The new “living standards” make this much, much harder. It is like building on quicksand: you can’t target a stable version of these standards. There’s also no sane changelog to speak of, as far as I know. The RFC standards we used to have were quite sane, but all formalisms are slowly being removed, which makes interoperability unnecessarily hard.

                      2. 2

                        I feel like the Node.js on ChakraCore effort was dead-on-arrival. The Node.js/JavaScript ecosystem already has a hard enough time with native interop that trying to abstract it away was premature. It’s still possible that the ABI Stable Node API work takes off but, sitting here speculating, it doesn’t seem to have enough of a benefit to developers to warrant packages switching.

                      1. 6

                        “Geospatial” or “geo” might be less-cryptic tags but I agree with the recommendation!

                        1. 1

                          Geospatial would be the better of those two options, I think

                        1. 1

                          macOS Safari didn’t like that link either

                          Safari:

                          Version 11.1.2 (13605.3.8)

                          macOS High Sierra:

                          10.13.6 (17G65)

                          1. 12

                            Despite having the console open in another tab, having used it recently, this was the hardest quiz I’ve taken in a while.

                            1. 1

                              I guess that many people don’t even use the console (by using terraform or Amazon’s equivalent), that would explain the results.

                            1. 6

                              I really like Stack Overflow.

                              Based on anecdotes and internet comments I feel like I joined the site just as it was becoming more “difficult to get into” and “difficult to earn reputation on” and certainly before it became particularly “aggressive” with duplicates and low-quality questions. I’ve also had quite a bit of luck with silly questions getting a good number of upvotes (and I’ll even go as far as to say that they aren’t good questions if I’m honest). That’s all to say that I very well don’t really understand what new users go through nowadays.

                              It makes me sad when someone get downvoted for posting a duplicate. We should better surface them in the posting flow, but it’s not reasonable to expect askers to find dupes consistently. Users aren’t “too lazy” to search; searching takes less work than posting.

                              One trope that grinds my gears though is the “Stack Overflow closes everything as a duplicate”. I don’t really see it. A lot of people won’t bother searching and I do think that searching for a duplicate is more work than just posting a new question, especially when someone new to programming doesn’t know all the weird terminology.

                              And little makes me sadder than comments on answers saying, “Don’t answer questions like this – it encourages them.” Now, some questions are off-topic. (I’m genuinely sorry, but we simply can’t explain how a glass pitcher can smash through a brick wall with no apparent injuries; we are a programming site.) But it’s totally cool to answer questions without giving a grilled poop sandwich about exactly what’s allowed. It’s fine to volunteer in one way without being expected to read and enforce every rule and meta discussion since forever.

                              I’ll be the first to admit that I was on this bandwagon for a brief bit of time. A lot of questions posted to the site from users with 1 reputation (a sign they’re new) are an error message asking “why?” and I felt (and still feel?) that rewarding that sort of behaviour in a learner does them a disservice. I’d love to hear folks’ thoughts on this: what’s the best way of answering questions online without a million comments back-and-forth (something that SO doesn’t really facilitate)?


                              I’ll just plug the link hidden at the bottom of the article again: Stack Overflow Inclusion Project

                              We’re looking for volunteers to share their experiences in chat with us and help us prioritize what to work on first. Whether you’re an active user, or someone who isn’t comfortable participating, if you’d like to help, please fill out this one-minute survey.

                              1. 8

                                I think what’s termed a Necessary Jerk here is also referred to as a Brilliant Jerk in case anyone’s looking for related thoughts:

                                Anyhow, I agree with the article.

                                1. 10

                                  Helpful hint: you can turn slack notifications off.

                                  1. 9

                                    When I did this my coworkers got super mad I wasn’t answering things promptly.

                                    1. 3

                                      Do they get mad when you try to negotiate for “Do No Distract” times in the day?

                                      1. 4

                                        We didn’t have a culture where people actually followed that. You could have a do not disturb time but people would interrupt you anyway. A couple of us started making fake meetings just to get some time to code.

                                        1. 3

                                          Ouch. It’s telling when things get that bad.

                                          1. 2

                                            A couple of us started making fake meetings just to get some time to code.

                                            It’s a good trick, I’ve been doing this for years so I could make sure I got lunch and time to do work.

                                            1. 3

                                              Wow. These comments, and the recent thread about maybe not working long hours, paint a bleak picture of current work practices in the US.

                                        2. 4

                                          get better co-workers

                                          1. 1

                                            I actually got the different answer. I was using slack as a message queue, when I saw a coworker that I wanted to distract, I’d slack them (via the app) and wait for an answer, but they actually prefered me to come to talk to them and bother them.

                                            I found this weird but complied…

                                          2. 7

                                            If you read the article, notifications are only a very small part of the problem. The author was speaking about wide scale effects happening at the organization level.

                                            1. 3

                                              This. So much this. I know that the discussion can take different forms and sometimes there are also larger organizational issues at play. But with that said, I think people often forget that they can disable notification on devices. I’ve seen co-workers across two companies leave notifications on for every single message in a channel (yes, you read that correctly) and with sound nonetheless. It baffles me.

                                              macOS comes with a built-in Do Not Disturb mode. Slack lets you configure your notifications so that you’re not getting notifications for each single message across a bajillion channels.

                                              [Slack] normalizes interruptions, multitasking, and distractions, implicitly permitting these things to happen IRL as well as online. It normalizes insanely short reply times for questions. In the slack world people can escalate from asking in a room to @person to @here in a matter of minutes. And they’re not wrong to – if your request isn’t handled in 5 minutes it’s as good as forgotten.

                                              Somewhere along the way we forgot that interruptions are toxic to real work. It wasn’t always this way. On day 1 of my first trading job the only instruction I received was ‘when the market is open, mute your phone.’ The subtext was ‘or else’. If someone said this to me today I’d give them a hug, and I’m not a hugger.

                                              I think people need this reminder today. Outside of work I see people with group chats on their phones (be it Facebook, Twitter, Hangouts, whathaveyou) that bleeps and bloops without rest. I can’t imagine living in that world.

                                            1. 11

                                              I’d just like to say thank you.

                                              Your talks and podcast appearances are both informative and entertaining, and you’ve made me interested in low level topics that I’d otherwise not be exposed to (I’m thinking of your trilogy on BSD Now where you talked about epoll weirdness, if I’m remembering correctly).

                                              I’m not exaggerating when I say that I’m going to watch everything listed here.

                                              1. 1

                                                Could you link to (some or all) of these podcast appearances you talk about? I’d love to listen.

                                                1. 4
                                                  1. 2

                                                    The BSD Now episodes (a subset of @bretthoerner’s link):

                                                    The three episodes are available as one merged episode:

                                                    There are links to audio versions and RSS feeds above the show notes at the bottom of the page.

                                                1. 18

                                                  The article seems to put forward two seemingly separate arguments, that localStorage is not a good API and that localStorage is insecure. I see these as separate issues. I don’t have a particularly strong opinion about whether or not the API is good or bad, it is what it is. However I do think that calling localStorage insecure is unfair. It’s no more secure or insecure than anything else in the browser: if you’re giving 3rd parties access to your website you’re inherently trusting them.

                                                  Things are getting completely out of hand.

                                                  Almost every day I stumble across a new website storing sensitive user information in local storage and it bothers me to know that so many developers are opening themselves up to catastrophic security issues by doing so.

                                                  […]

                                                  And the thing about local storage is that it is not secure! Not at all! Everyone who uses local storage to store sensitive information such as session data, user details, credit card info (even temporarily!) and anything else you wouldn’t want publicly posted to Facebook is doing it wrong.

                                                  [yadda yadda yadda XSS]

                                                  So to err on the side of caution and dramatically reduce your risk for a security incident: don’t store anything sensitive in local storage.

                                                  The argument boils down to “don’t use localStorage because it’s susceptible to XSS attacks” and I disagree wholeheartedly. XSS is basically game-over in the context of a website, so building your application under the assumption you’re vulnerable to XSS is, I think, misguided. I think it’s better to work your darnedest to prevent XSS attacks, and between Content Security Policy (CSP) and Subresource Integrity (SRI) I think developers have the tools they need (in modern browsers, granted*) to do so.

                                                  * That said, the author talks about using SameSite=strict, which has poorer support than CSP 2, let alone CSP 1.

                                                  Don’t tell me that JWTs are “stateless” and “fast” and you have to use local storage to store them: you’re wrong!

                                                  JWTs are stateless and they are “fast”. Neither of those things are negated by the fact that you can use localStorage to store them.

                                                  NOTE: For those of you who made it this far who are wondering if I didn’t read the article in its entirety because the author has notes at the bottom about CSP and SRI, I think CSP and SRI are solutions to the problems they’re describing and they seem to have tacked on hand-wavy dismissals at the end. The combination of CSP and SRI prevent XSS. The people who can’t use SRI because of 3rd-party ad networks or whatnot are inherently trusting those resources.

                                                  The article would be better to say “if you’re blindly trusting 3rd-party code, know that they can read your localStorage values and think twice” instead of trying to make sweeping the claim that localStorage is insecure.

                                                  1. 4

                                                    The article seems to put forward two seemingly separate arguments, that localStorage is not a good API and that localStorage is insecure. I see these as separate issues. I don’t have a particularly strong opinion about whether or not the API is good or bad, it is what it is. However I do think that calling localStorage insecure is unfair. It’s no more secure or insecure than anything else in the browser: if you’re giving 3rd parties access to your website you’re inherently trusting them.

                                                    You hit the nail on the head. Sorta.

                                                    I don’t really think local storage is bad or anything, but it just seems like it has a really limited use case. What really annoys me and what prompted me to write this article is the common pattern now-a-days (adopted by 99% of web developers) where you authenticate a user, store their usre info in a JWT in local storage, and somehow believe that makes the site more secure than a cookie.

                                                    I just wanted to emphasize how widespread XSS is, how easy it can be for your most sensitive data to be stolen (your session token), and why it’s not a good idea to trust local storage for sensitive information.

                                                    Finally – towards the bottom of your response you mention the thing about JWTs being stateless and fast as incorrect. JWTs are stateless (and fast, sure, once they’ve been sent to the server), but:

                                                    • Using a stateless JWT makes you store a lot of user info in a token which ends up making it larger (>4mb for almost all my sample apps). This means I’m now required to store it in local storage as cookies cap out at 4k.
                                                    • Using JWTs requires you to build centralized revocation list patterns into your server side app (unless you don’t really care), and that requires centralization again – so you lose the stateless benefits of the JWT.
                                                    • Using JWTs in local storage means you’ve now got to send a much larger amount of data to a web server on every request. This feels like a bad tradeoff to me. Datacenter networks will always be faster than consumer networks, and it doesn’t make sense to me to push the burden of extra data transmission to the client.
                                                    • Using JWTs for auth means you’re directly reducing security (speed/security tradeoff). The best practice in the security world is to always perform authn/authz in realtime to get guarantees. This is impossible by design in JWTs.

                                                    I’m just a fan of using normal sessions and keeping things simple. I wanted to present an argument for why I think it’s a better strategy and give people something to think about before blindly choosing to store sensitive info in local storage =)

                                                    1. 1

                                                      You missed “localstorage auth can only work with JavaScript, so your site probably sucks to use”.

                                                      Having to load the page, parse the script, then send another request and put the results into the DOM is much slower than just serving the content in the first place.

                                                      1. 1

                                                        What really annoys me and what prompted me to write this article is the common pattern now-a-days (adopted by 99% of web developers) where you authenticate a user, store their usre info in a JWT in local storage, and somehow believe that makes the site more secure than a cookie.

                                                        Maybe my point is this: the “security” of cookies and the “security” of localStorage are incomparable. I don’t think it’s correct to say one is more secure than the other. Everything in software development is about tradeoffs, to your point. They have different attack vectors and require different approaches to securing their usage. Cookies are susceptible to CSRF and localStorage is susceptible to XSS (both probably amongst other things).

                                                        How about I propose this hypothetical: if XSS wasn’t a thing, would it then be fine to store “sensitive” information in localStorage? I think yes. If so, I think it’s more useful to work towards preventing XSS than assuming game over.

                                                        I just wanted to emphasize how widespread XSS is

                                                        That’s a good thing to do, I agree that web developers sometimes don’t realize how susceptible their applications are. That said, I again think the article would be better to say “if you’re blindly trusting 3rd-party code, you’re susceptible to XSS, they can read your localStorage values, and think twice about using localStorage” instead of trying to make sweeping the claim that localStorage is insecure.

                                                    1. 5

                                                      I’m curious as to Google’s motivation for Fuschia: what does it offer over Linux?

                                                      1. 26

                                                        They’ll be able to use a license other than the GPL and have a stable ABI. This would please a lot of device manufacturers

                                                        1. 4

                                                          Isn’t the Linux ABI somewhat stable? Isn’t that a sticking point for Linus, not breaking userspace?

                                                          1. 12

                                                            The syscall interface is stable. The ABI for kernel modules/drivers is not.

                                                            1. 2

                                                              If this is the main objective, didn’t they “solve” this with Android’s new hardware abstraction layer?

                                                              Rebuilding from the ground up seems like a huge amount of work when we can build up piecemeal stuff pretty nicely

                                                              1. 9

                                                                I doubt the ABI chances have been solved with the /vendor partition. As I understand it, this change just allows for a clear separation between what is and isn’t the core Android system. Manufactures can still have binary blobs in /vendor and not release their customizations and plugins kept there. ABI breakage happens at the Kernel level, and can only be solved in the Android world if Google forced all manufactures to one standard Kernel for all devices.

                                                                The GPL is also something they can’t solve either. This is probably the saddest part of the Fuchsia project, and echos Google releasing Chrome after drumping so much money into Firefox. They support the OSS tool, but then dump them because they want their own control and licensing. Their new tool is still OSS, but with a license that’s better for them. I wrote about how companies embrace/use OSS a while back:

                                                                http://penguindreams.org/blog/the-philosophy-of-open-source-in-community-and-enterprise-software/

                                                        2. 11

                                                          We’ve seen a large number of Google devices coming to market (tablets, phones, notebooks). I wouldn’t be surprised if they were on their way to an “Apple”-like hardware mode where we have a 3rd, proprietary, but fully integrated environment to choose from. MSFT has the same sort of model going, with the Surface line of things, so it could be that we have an all out war between MSFT and Google for the next generation of business machines. I mean, look at the product lines:

                                                          • Office: Covered by both, with MSFT having the product to beat
                                                          • Email/Calendaring/Collaboration/etc: Exchange / Sharepoint vs Apps for Business
                                                          • Managed “IT” services: Windows Server (run yourself, with domains etc) vs. Apps for Business

                                                          Apple isn’t a threat to MSFT in this space, though it has a lot of similar, consumer grade, products.

                                                          Obviously, there’s a bootstrapping problem for Google here, but, I’m sure there’s nothing stopping the Fuchsia team from running a Dalvik VM, or making Android apps run seamlessly on it, and I’d fathom that that’s part of the plan for adoption, with Dart/Flutter being the answer to C#/.NET.

                                                          Google recently killed off Chrome Apps, so it seems that extending the Chromebook beyond running android apps, and Chrome Extensions (very limited as far as I can tell) will lead to an eventual death for the Chrome OS line of products.

                                                          So, you have the ability to take what you’ve learned from Chrome OS, integrate all the hosted “cloud” stuff seamlessly into a full feature operating system that has better native app abilities? Seems like a lot of potential to gain market share, especially, as they are doing so in the open, where “what’s this Fuchsia thing?” is being asked about, people can look at, play with it, and audit the design, source code, and, of course, write blog posts about how it’s broken. Basically, they’re in a really good position here, technically, and from a marketing standpoint. It markets itself! And jeesh! Think of all the baggage they are eliminating by starting fresh.

                                                          Black hats are salivating, and keeping track of all the errors that are being made in commits, just hoping that they become exploitable in some future, after aging a couple years without being touched….

                                                          1. 7

                                                            See the linked article in the article about how Google likes to build two of everything. I figure it’s essentially a hedge. If it turns out to be awesome in some way that Linux can’t be, they can move to it. If it turns out they need to do something they can’t do on Linux, they have this other OS all ready to go. If it turns out that it doesn’t do anything as well as Linux-based systems already can, then they aren’t really out anything but some money and engineer time, which they have plenty of. Google likes to do this in a number of domains to ensure that they stay on top no matter which way the industry goes.

                                                            1. 11

                                                              Linux has accumulated a lot of irrelevant features (attack surface) over time?

                                                              1. 4

                                                                They have the money and time to do it? Or perhaps they are tired of trying to make the fragmented android / linux ecosystem work for them amd want to take a new approach they can fully control. Ui-wise I’m happy to see that it seems to have a functional out-of-the-box app launcher ala Kiss, though I guess any ui component will massively change in the future.

                                                              1. 6

                                                                I spend a lot of time during the year watching conference talks and I love sharing ’em.

                                                                My favourite (off the top of my head): Principles of Technology Leadership - Bryan Cantrill. Bryan Cantrill is easily one of my favourite speakers and this talk addresses the relationships between principles+values and software, something that I’ve been thinking about a lot lately in one form or another. I think a lot about what role software plays in society and how software developers and software companies can shape society for better or worse and this talk was right up my alley.

                                                                Honourable mentions (really just looking through my YouTube favourites & history):

                                                                1. 1

                                                                  I’m not a Ruby developer but boy oh boy does RubyConf and RailsConf have some great talks year after year.

                                                                  1. -1

                                                                    Technically Wrong: Sexist Apps, Biased Algorithms, and Other Threats of Toxic Tech - Sara Wachter-Boettcher

                                                                    My AI assistant does not understand me, this tech is toxic. So much bullshit in this talk

                                                                    1. 4

                                                                      I downvoted you as a troll because you watched an hour long talk (giving you the benefit of the doubt that you watched the whole thing), then took 30 seconds to call it bullshit without making any real arguments or providing any worthwhile input.

                                                                      You think it’s bullshit. Neat. Anything interesting or substantial to add, or did you just really want us to know how you felt?

                                                                      1. 2

                                                                        worthwhile

                                                                        I just said its a bullshit, relax. And yeah, I think it’s bullshit that a single cry baby can shutdown application because the application cannot understand how the cry baby feels.

                                                                        PS: Understanding hour long talk does not require a time consuming deep thinking process