1. 12

    I think of Material Design more of a safety net. We can’t expect every app maker to be proficient in design and creating something interesting, unique, and useful. MD saves the average app developer from making a really really terrible app. Yes, you still have to understand the design philosophy, the guidelines, the patterns. But it’s easier to use a set of components Google has made for you and copy patterns that occur in the MD-complaint apps.

    Disclaimer: I work at the GOOG.

    1. 8

      As a backend developer that has had to take on the lead on a few front end projects, this is a massive win. You can simply follow material design spec and get solving problems, then when someone queries why you have done something or wants something changed, you can just quote the material spec and get on with solving real problems.

      1. 7

        “real problems”

        1. 3

          and get on with solving real problems.

          I think if the application in question is small enough, then this might hold true; however once the project gains any significant complexity or scope then I’d say having a backend developer work on UI might cause a few ‘real problems’ of its own ;)

          1. 3

            This an example of the kind of conclusion you don’t want to jump to. Material Design may be a good stand-in, but it is ultimately a one-size-fits-all solution to a problem (yes, a real one 😉) that is inherently case-by-case. It helps developers speed through UI design; it does not solve UI design. As much as Google may want you to believe that convenient untruth.

        1. 1

          As someone that is currently migrating/migrated mvc/applications to an Spa/rest platform, once a competitor in the same field does, in order to offer the same front end features/“experience” , e.g heavy JS front ends with lots of different libraries, an Spa is just easier than maintaining multiple JS scripts via templates. It also means you can have a solid rest backend and change the fronted as required.

          I personally use angular for front end code and there are some great tutorials and articles that help/guide users towards server side rendering on larger applications (works well at enterprise level) . Currently it is just easier to use/create an Spa that not (when using lots of JS libraries), it’s not the most enjoyable of experiences, but… Users want features and others want a clean/maintainable/lts/supported code base.

          1. 1

            I don’t even have to read this to up-vote it.

            1. 9

              You might still want to read it and maybe reconsider that upvote. That article goes all over the place, stating its thesis that blockchain hype is the new NoSQL hype, that the NoSQL haters were right, that both of those terms are vague enough to be meaningless, and conclues that blockchain is a very exciting technology and that we should all join the author’s company VMware to work on it.

              ¯\(ツ)

              1. 1

                It was just a joke, expressing my views on blockchain technologies, e.g great in theory, but not the answer to every problem. Similar to my previous (and current) views on NoSQL.

            1. 9

              After 2 years my experience with Vue has been positive. I’m still confident it was a good decision to move my team from React to Vue. Not because Vue is better, but because it is a better fit for us.

              Why though? These comparisons of libraries/frameworks that amount to “differences of technical details” are not worth writing. Did the author have some problem that couldn’t be solved with React and could be solved with Vue? That would be worth hearing about. I’m talking real business-value-added problem solving. Not “the syntax is nicer”. If I was employing this author and read this article, I would feel like the migration from React to Vue had been a waste of company resources.

              1. 1

                Well ultimately they are both Javascript frameworks, so what you can do in one you can do in another, the whole idea of a framework is the syntax in which you interact with it to the base language. As such, some things will be easier in framework X and other will be easier in framework Y. In my opinion you have the Angular way to solve JS “framework projects”, then the React way, Vue sits a bit in the middle (if not closer to React).

                1. 2

                  what you can do in one you can do in another

                  If I’m already using a tool that can do what I need it to do, why would I invest in a new tool? And I don’t mean to reduce things to “it’s all JavaScript so you don’t need a library”. React, Angular, Ember, Vue, etc., are compelling to me to the degree that they enable a developer/organization to deliver useful software. But if React and Vue are compelling to the same degree, I’m not sure there’s anything to talk about.

                2. 1

                  Author here.

                  The article was getting pretty long already and I didn’t want to get into those points.

                  Did the author have some problem that couldn’t be solved with React and could be solved with Vue?

                  There were 3 major paint points for us with React. That was in 2015-2016, at the end of 2016 we moved to Vue.

                  1. JSX is ok for JS devs, but terrible for designers that work with HTML and CSS. We tried to solve that using a Wix library called react-templates but it introduced its own set of problems.

                  2. React Router was cumbersome compared to Vue Router. For example if you need to access the router from a component you needed to create a HOC. We also hit a bug that could only be solved by using setTimeout() with 0 delay. We quickly found that the React Router team was not very welcoming to feature requests or bug reports, to put it mildly. Vue Router in comparison made a lot more sense and was much easier to deal with.

                  3. Managing local state compared to Vue is tedious. We considered moving to MobX, which is what a lot of React guys are doing, but at that point I gave Vue a try and it was immediately clear that it was a better fit for us.

                  If I was employing this author and read this article, I would feel like the migration from React to Vue had been a waste of company resources.

                  We didn’t rewrite our React projects to Vue, if that’s what you are implying.

                1. 2

                  I never really understood the sabayon distribution, its Gentoo for people that can’t install it, or don’t want to spend the time to. For the people that just want to save time, that’s great, but usually Gentoo users, don’t want anything but the bare essentials there use flags have pulled in on there chosen packages. As an ex Gentoo user (probably around 2006-2008) I remember the forums and irc channels just being packed with sabayon users who had installed it, then running into to problems when emerging something else.

                  I can’t applaud the installer enough as I remember it used to be very easy/efficient to use, however as an ex portage user I didn’t personally enjoy entropy. I would have thought it would have been better to just maintain a Gentoo installer and entropy package separately. I remember back in 2006(ish) Gentoo released a live CD installer (which was awful) and then Sabayon came out with one (I think either just before or just after) that worked perfectly.

                  Anyway, it’s great to see this project is still around and doing well.

                  1. 1

                    It seems like a cop-out because the whole point of Gentoo is building the package to fit your system. Sabayon has a number of precompiled packages. Seems to defeat the purpose.

                    1. 1

                      There are people who would like to use perks that emerge/layman gives them (first class access to application’s source code, build process, etc), or would like to learn Gentoo, but don’t have knowledge or will to install it properly. I’ve used Gentoo in times of Penium4’s and I liked it very much, but the duration of revdep-rebuild was simply horrible, updating Firefox or OpenOffice was something that needed to be scheduled over night. So I understand that some people would like to have a system that’s prepared for them, and use Gentoo’s tools for the customization of software they are interested in customizing.

                  1. 2

                    I don’t mean to be rude, but python 3 has been around and the preferred python for Web development for some time, the fact that the migration needed to make a blog post is a bit over the top.

                    I personally switched all my django projects to pyramid over 5 years ago now, mainly for as the post suggests, the ‘django’ method of development is heavily influenced by lots of third party plugins, which causes dependency hell come upgrade time. And (from my experience) you may only need 10% of the plugins capabilities in your application. And usually what would break these plugins wasn’t python, it was djangos framework code.

                    For a company so reliant on a Web front end, I would have seriously considered swapping out third party libraries some time ago, but that’s just me.

                    Anyway, the point to my rant is that python 2 - > 3 is in reality (for this use case, Web) a daily non trivial task. Hence why one year at PyCon everyone was talking about it (in angst of the upgrade) and next year no one was, (because, in most cases, even for large projects its only a day, or two, max).

                    1. 0

                      So this means whatever you write in python today, you will have to re-write it again in 8 years ?

                      https://en.wikipedia.org/wiki/History_of_Python#Version_release_dates

                      Maybe tools like 2to3 make it easier though…

                      1. 8

                        Guido has shared this article stating that no more breaking changes are expected in the future :

                        a 4.0 will presumably still happen some day, and the premise of this article is expected to hold for that release: it will be held to the same backwards compatibility obligations as a Python 3.X to 3.X+1 update.

                        1. 1

                          This is a great news!

                        2. 4

                          Basically none of the Python community wants to experience the 3.0-style backwards compatability issues again (this includes core developers).

                          Something that might get lost in the noise, but 3.0 in particular broke a huge amount and there was relatively little concern for having code that could run in 2+3. But after the feedback they had introduced stuff back into 3 (like allowing the no-op u'..') and made it easier to run both-version-compatible code. So 3.0 was especially broken.

                          Guido has said that any compatability breakage nowadays would happen piecemeal, and with more care to this issue. Presumably it would have been something like “string literal changes” in one release, “urllib changes” in another release, etc. Instead of forcing all changes all at once.

                          1. 4

                            So this means whatever you write in python today, you will have to re-write it again in 8 years ?

                            That’s a completely unfounded statement.

                            1. 5

                              Ended with a question mark, I’d assume a legitimate question. Also the answer to it would be “not necessarily, and if you’re writing it in Python today, this might convince you to write it in Python 3”

                              1. 1

                                I am still new to python, so this is more of a clueless question than a statement like olivier wrote.

                                So as I understand it, it might have been the case 8 years ago, but as edudobay points out, what comes will be much better.

                                1. 4

                                  When I migrated 8 projects from python 2.7 to 3.4 (few years ago now) it only took me about a day, it really wasn’t as painful as it was made out to be. Before any big changes are planned the documentation usually suggests ways to structure current code that won’t break future releases.

                                  1. 1

                                    Then I understand what lead me to thinking this: I have seen a quite large code base (glue between daemons and an API) wait till the latest minute (now I guess) before to switch from 2.5 to python 3.

                                2. 1

                                  I understand what lead me to think this (as answered to crookey).

                                3. 2

                                  I’d be suprised if they were to actually include a switch, which would any python2 interpreter just immediately quit whenever it’s started after 1/1/2020. But guessing that they won’t do that, I’d suppose that most people will be allowed to keep on using the interpreter, even if it isn’t maintained anymore.

                                  1. 2

                                    That’s my reading too.

                                    In any case, there’s nothing stopping someone from forking the code, as Guido points out.

                                1. 2

                                  The whole Python 2/3 debacle is why I gravitated to Ruby, which has its own set of warts.

                                  So what are the lessons learned?

                                  1. 2

                                    Incidently, the reason I moved from Ruby was the 1.8 era where I think there was also a rails 2/3 upgrade at the same time, wasn’t fun. Lesson learned is the one of the biggest obstacles of our job is unsupported software, be it a library or a language, as long as it works and solves your problem, it’s not the end of the world.

                                    And just because software is marked as unsupported, it doesn’t mean all the knowledge for X software projects also disappears over night.

                                    Or we can just write everything in assembly.

                                    1. 1

                                      No matter what tools you choose to use there are going to be things you don’t like about them. And that’s okay, you just have to pick a set of warts you can live with.

                                    1. 4

                                      Interesting article, however to me this everything that is wrong with open source software, in the good old days (and still around 50% of the time now) open source software (and contributions) come around when people need to solve X problem, and opensourcng your work is a great way to help others, then usually if the code is found to be useful (or in demand) then contributors join in, and before you know it you have some code you wrote to help you out on a project, working for thousands of users in ways you never expected.

                                      “Necessity is the mother of invention” is a very fitting statement for open source (in my opinion). Creating software for a problem you don’t have (or that doesn’t exist) seems very counter productive, this whole attitude of wanting to create an open source project for “Internet points” absolutely perplexes me. If you want to help the open source community there are thousands of projects that would love the help.

                                      Marketing open source software? I mean put it on Github with a decent readme and a search engine will take your potential users there, however if you created some software for a problem that doesn’t exist, don’t expect too much traffic.

                                      Testing is a good point, but usually in smaller scale open source projects (or single maintainers) you write the code to solve a problem you have, maybe there are a few tests, but to me if I found a piece of software that did what I wanted, and had no tests, I would just write my own tests, we have so many users of open source software now that just seem to moan or log issues when it doesn’t work for them, when in reality they should be sending pull requests (or diffs if you took your dinosaur to work) saying “hey, cool project, I used it but noticed you had no tests, I creating the following, hope this helps”. However, I can count on my hand the amount of times I have seen pulls/diffs like this.

                                      I have gone off on a bit of a tangent, but hey.

                                      1. 2

                                        What part of the OP, exactly, implied that open source today is all about “Internet points”? Don’t you think that’s just a tad bit uncharitable of you?

                                        I also think your thoughts on testing for small single maintainer projects are way off the mark. I wouldn’t be able to maintain the projects that I do if I didn’t have tests. There would just be no feasible way. I would probably need an army of clones of myself working in concert to do it.

                                        I think basically everything else you said is off the mark too, speaking as someone that has been involved in open source since 2003 or so. I remember the “good old” days before Github, accessible CI, emphasis on docs and testing, etc., and frankly, we are in a much better state nowadays. I mean, those days sucked. Hard.

                                        1. 1

                                          Add testing, documentation, build, distribution, marketing…

                                          Almost like they are building a product but without any plan for sustainability.

                                          1. 1

                                            Could you unpack that? All of those things seem beneficial with respect to sustainability.

                                            1. 1

                                              Spend hundreds of hours building something polished, lots of users show up asking for support and then burnout happens. Who maintains the maintainers?

                                              1. 1

                                                If your goal is to release something that others use and to incorporate feedback from others, then testing, documentation, distribution and all that stuff improves the sustainability of the project.

                                                If you’re just looking to throw something over the wall and don’t care whether anyone uses it, then don’t polish it in the first place?

                                                Like, isn’t this whole thing trivially solved by just asking the simple question, “What problem are you trying to solve?” Instead, people seem intent on bantering about “Internet points.”

                                                1. 1

                                                  If your goal is to release something that others use and to incorporate feedback from others, then testing, documentation, distribution and all that stuff improves the sustainability of the project.

                                                  This is contrary to every small OSS project I’ve ever seen. I’m speaking mostly of single person projects. Perhaps you are thinking of large, multi-person projects, e.g. Rails, Rust, etc but those usually have full-time people paid to work on the project. That’s the key bit to sustain it: a paycheck.

                                                  1. 2

                                                    Perhaps you are thinking of large,

                                                    Uh, no, I’m not. I’m speaking from my experience maintaining mostly small single person projects in my free time.

                                                    1. 0

                                                      Watch the “Uh”. It’s patronizing. Be kind.

                                                      At this point I’m not sure what we are discussing anymore so I’ll leave it here. We are likely looking in the same direction but with different angles.

                                          2. 0

                                            wanting to create an open source project for “Internet points” absolutely perplexes me

                                            I think it’s money that has entered the equation, and “internet points” are just an indirect means. An upside is that now there’s an additional incentive to make things. A downside is that now there also is an additional incentive to advertise.

                                          1. 1

                                            An interesting quote I stumbled upon last week “The ‘s’ in IoT stands for ‘secure’ “ - quite an apt comment I thought. The whole nature of “IoT” is connectivity no matter the costs, users for some reason see the benefit of having their fridge connected to their home WiFi, but the vendors (as a majority) never release a firmware patch or update in the wake of new vulnerabilities, this was apparent earlier this year with the findings of KRACK.

                                            Vendors now are too interested in shipping a working product, as opposed to a well tested extendible product, because they want to force you to buy new products when yours gets old, or if they add a facetime feature so you can facetime your groceries from work. No wonder so many people struggle for money these days, people just get sucked in.

                                            With regards to the article, TLS (and SSL) provide security between the connection origin and the destination, if your cheap device was rooted at another point, this becomes worthless.

                                            1. 2

                                              I have always used an old school IBM mechanical keyboard, the latest trends seem to have keyboard layouts as shown in the article, does this actually improve comfort and feel better after 8hours of constant use? I was looking at trying one out, but none of my friends have one, and I don’t live anywhere near a place that would have one for demo. Thanks.

                                              1. 2

                                                For me, the split keyboard was the largest improvement.

                                                I blew out an arm on an IBM Model M, had to switch to kinesis, and now ergodox. The largest issue was that my wide shoulders meant my hands were turned outwards when on the keyboard, and that put strain on the inside of my wrists.

                                                With my current setup, the distance between my F and J keys is twenty three inches (just checked), allowing my arms and wrists to relax.

                                                1. 2

                                                  This depends on your typing style, I think. For me the change to a columnar stagger and the change to using an fn layer for numbers and punctuation made a much bigger difference in comfort than going to a two-piece keyboard; I guess because of the reduced finger travel?

                                              1. 2

                                                I would love to run OpenBSD on my servers, for some of the reasons noted in this article, high code quality and the desire to run a clean system, however these same reasons also make it not such a great choice. When you administer a server, you unfortunately need to install an obscure package, or a library that doesn’t have an openbsd package, and then it just becomes a pain. At least with FreeBSD I never run into these issues, I can build everything from source, or if I need one program that I don’t want to build, I can just install a binary blob. I really admire the OpenBSD project for its principles and what it does for the open source community, but as am operating system I don’t personally get on with it.

                                                Also due to the scale in which FreeBSD is used commercially, as opposed to some of the other projects, you find more guides on line, so when you inevitably come across a ports build error (installing said obscure package) the solution is never far away.

                                                1. 1

                                                  I just started writing JS for our internal CRM and other applications, and although it doesn’t really bother me, I do find it strange how npm install (some package) takes so long, like I can build packages from source in FreeBSD quicker than I can install one module in npm. If the code behind this ever makes it to a local application, it would certainly be a big improvement. It probably only works in development though, as when bundling your applications, you may need a file that turbo hasn’t fetched, and depending on your builder picking this up, it could cause a few headaches/problems debugging production runtime errors.

                                                  Regardless of the above, the software engineering behind this sounds very impressive and it’s nice to see a startup actually solve a real world problem.

                                                  1. 2

                                                    If npm speed is bothering your, I highly recommend trying https://yarnpkg.com/ – it can pretty much be used as a drop-in replacement for npm that just makes everything faster (and takes up less of your drive space)

                                                    1. 1

                                                      Up until I read the post in this thread, I have never heard of yarn, I have only been writing JS for a few months now. I have just given it a quick whirl and it seems fairly decent,I will see how it fairs over the next few months and how it compares etc, thanks :-).

                                                      1. 2

                                                        I moved from yarn back to the official npm client when they released v5. npm currently also caches packages :)

                                                  1. 1

                                                    Very cool, and I need to do something very similar for an upcoming project, this helped a lot!

                                                    1. 5

                                                      I’m setting up my base station for amateur radio! I just got a power supply and antenna for my IC-7100, and I’ll be listening on the air soon.

                                                      1. 1

                                                        Nice, I always wanted to get into ham radio but never managed to make enough free time.

                                                        1. 1

                                                          It’s never too late! http://www.eham.net/newham/

                                                          1. 1

                                                            What discouraged me was the sheer amount of real estate a setup would take on my desk. I don’t have the luxury of having a free room to dedicate to the hobby, so my study would have to house all the extra kit, which I simply don’t think it would!

                                                            1. 1

                                                              A handheld radio is not much bigger than a cell phone and it’s a good first radio to purchase. No need to buy a huge base station until you’ve gotten more familiar with the hobby!

                                                      1. 0

                                                        Isn’t the best practice not to use node for server side code?

                                                        1. 1

                                                          Works fine, modulo the edge cases of your business logic and its expression in JS.

                                                          1. 1

                                                            Hum… no. I’m far from being a fan of Node but I do understand the usage of it. This reads almost as a bare troll to me….

                                                          1. 2

                                                            I have just finished writing two Javascript Spa’s (my first time doing any JS work). These two applications save our business over 80man hours a week in what they can offer (opposed to our stock and expensive ERP solution). I have a third to write which will be replacing our old python/html powered CRM system with a full JS front end and separate backend (much like my recent creations) but I just need to decide whether to stay with the Python/Angular stack, or try another language on the backend and possibly Elm for the front end. The backend is 90% sql, so I really don’t see any immediate advantage moving from python (and sqlalchemy which makes maintenance and feature requests super easy)

                                                            1. 1

                                                              You could connect to a public proxy and force all traffic through it, it will be slow as hell and very limiting on what services will work.

                                                              1. 2

                                                                I really wish there was a first class, stable/maintained docker port for FreeBSD. There are a few forks that are in various states. Last time I tried, I could get my containers running using the local docker client, but trying to connect to it remotely with a newer version of the docker client would fail.

                                                                Having a solid docker solution would be a big game changer in the FreeBSD world.

                                                                1. 13

                                                                  Having a solid docker solution would be a big game changer in the FreeBSD world.

                                                                  Perpetuating a level of mediocrity. How about going the other direction and organise things so you don’t need docker as a “solution” in your environment. That would be a far bigger game changer.

                                                                  1. 5

                                                                    +1 docker is an easy way to deploy applications for people with less sys admin experience, but docker more of a development tool, but in my eyes, not the beat deployment technique.

                                                                    If you really want docker on FreeBSD fire up a bhyve instance of Linux on BSD, and run docker there. Emulating Linux on bsd works really well on bhyve, having docker and freebsd together just opens your solid architecture up to problems, run it in a vm and if it eats memory or crashes, it won’t affect the master host.

                                                                    1. 2

                                                                      Yeah, I have a feeling nix + jails would be a better solution overall than docker on freebsd and probably already works fine.

                                                                  1. 10

                                                                    This quote sums up perfectly why I run FreeBSD on all my commercial servers.

                                                                    everything just worked neatly out of the box. I was amazed with the fact that after a few hours with FreeBSD, i had the whole stack running.

                                                                    Solid, reliable and secure. Yes there are more solid choices, yes there are more secure choices, but for me FreeBSD is a perfect balance of both, coupled with expert documentation (which is not unique to FreeBSD, its more of a BSD thing in general). And it’s real documentation from the *BSD website, not stackoverflow answers or out of date third party tutorials.