sn1de

I agree with your more nuanced take on the golang community's position. I still think that a fully realized framework is, in general, a better starting point for the vast majority of projects. Part of the problem is that such frameworks are few and far between. I'll stick to the Ruby community: I know developers I respect who really like Sinatra, which would be more akin to a microframework. It is their go to starting point, but when I go to work on their projects I very quickly find myself straying out of Sinatra's capabilities into things that are fully baked into Rails. I then have to spend time pulling that capability into Sinatra, which is not how I like to spend my time as an application developer. There are many frameworks that are positioned as 'elegant' or 'focused' when they are simply incomplete in the face of real world development and teams end up having to either cobble together disparate micro-framework or rebuild basic capabilities to get to a fully realized app. I would argue that is not time well spent and that everyone thinks they are super good at creating solid, performant, extensible, well documented code, but they are not (statistically speaking) and by then it is too late and others have to live with their junk for years, or worse yet they all bail because now they know hot-framework-x and board the recruiter train to their next salary bump.

I don't know the php ecosystem well at all. I just didn't want to come across as 'Rails is the only one true way'. Lots of php folks seem to love it, and it derives a lot from Rails, so I thought it was a fairly safe shout out. But, it is HN after all, so no opinion can be put forth without and equal and opposite negative reaction.

Yes, the state of the industry is a hot mess, but I'm not sure this article rings true. Failing to leverage good frameworks is as big a problem as over using the bad ones. I would point to Rails as an example of an appropriate framework (and Laravel if PHP is your jam). The trouble is so many others are bad, incomplete or defunct, but I don't think the answer is the golang mantra of 'we don't need no stinking frameworks'. Seeing mediocre developers reinvent the wheel, slowly and badly, is super painful and wastes time and money. If you hate the frameworks available to you then perhaps you should consider finding a better ecosystem. Relax your bias and follow the happy developers, wherever that may lead.

The x86 hardware and the Linux OS both had to make the jump to 64 bit. Sun was still able to make hay in the period where Linux was well established because 32 bit memory restrictions kept if from being a viable option for a lot of higher end computing needs. It was inevitable that Linux would eventually make the migration to 64 bit once the hardware was there, but Sun got there first on both the hardware and software fronts. Why Sun didn't react more radically when 64 bit Lintel was able to go head to head with Sun's precious 'enterprise' solutions is unknown to me. Maybe they were just in mass denial? Maybe they thought the technical hight priests within their organization would manifest new technical advantages? Maybe they just knew that if they dropped their pricing to address the new price/performance reality that their company was no longer economically viable? There was a lot of denial about Linux at the time, and there were plenty of legitimate reasons to question whether or not Linux could really make the leap to compete head to head with the leading commercial Unix offerings. Meanwhile, major efforts were being made by the likes of IBM and, ironically, Oracle, to contribute to efforts to make Linux a 'no compromise' commercial offering. Remember that companies like IBM had watched their own Unix offerings suffer from Solaris on the high end and Linux on the low end. The smart ones realized that Linux could be the answer to the hard sell they were running into with their own Unix and put engineering efforts towards making that happen. I'm not saying Linux wouldn't have gotten there without them, but there was a strategic shift that happened to accelerate the technical ascension of Linux, and that also caught Sun off guard. I suspect they had looked at the historical trajectory of Linux and over estimated how long it would take Linux to 'catch up' to Solaris. Linux went 'hockey stick' on Sun.

Agreed. In my mind, the M1 Mac I'm typing this on is a direct descendent of the NeXT workstation that launched while I was still a student with no hope of ever owning. As much as I love the progress, it does make me wonder where/how the next true breakthrough will come from, or will we just continue to evolve what we have for another few decades?

They were already doomed at that point. I was involved in several major purchase decisions during that period and Sun were totally out of touch. If they were quoting hardware that had an x86 equivalent, then they were overpriced. If it was something that didn't have an x86 equivalent, like they had for a while with 64 bit, the prices were atrocious. Then Lintel moved to 64 bit and it was all over. The price/performance equation was broken, but Sun, for whatever reason, kept on like nothing had happened. I, and I'm sure many others, tried to show them that they were uncompetitive, but you were dealing with reps working from a price sheet and citing the same old mantra that Sun was inherently superior. For years when I would tell peers that the Sun equipment was just throwing away money they wouldn't believe me because they hadn't done the benchmarking. Really, if people did proper benchmarking and didn't just 'buy what they know' without questioning, it all would have unwound even more quickly. They certainly had some good tech, and were not wrong about the advantages of containerization, which came full circle with linux containerization and docker, but IBM mainframes had similar virtualization capabilities in place long before Solaris zones, so it wasn't something that was a game changer. Ironically, it worked against them because even though they were right, it was seen by some as Sun touting their way of doing it because they didn't have a viable solution for the prevailing VM direction of hardware virtualization. Basically, they began by offering the best price/performance and innovation, but then died trying to be a 'premium provider' without the goods to back it up, and market forces then do what market forces do.

And instead we should all use ???

Hello?

If there is a business/domain need for this capability most organizations will go with some kind on content management solution (CMS) of which there are myriad solutions. Git would be considered bare bones and unintuitive compared with the best of these tools.

It competes with anyone selling point of sale hardware. I think Square falls into that camp, no? I wouldn't want to be in that space right now. I don't see how this doesn't usurp a big chunk of their market since it isn't even a decision between buy this or buy that, but buy that or just use the thing already in my pocket.

As in 'slight of hand' employed by a magician. Where someone makes an obvious movement to distract from something they don't want you to see. In this case, the assertion is that the Metaverse is more hype than reality. A shiny object, or concept, to create a plausible narrative that bridges Facebook into a future where they once again dominate, while distracting from the possibility that their current position is in decline with no tangible mitigation plan.

lol'd at this one. i have a new tv, I have gone to youtube several times now to figure stuff out, and I am well versed in a/v.

20+ years of web site ecommerce development experience and what I see is that consistently the designers and the managers and/or product owners (who have the final say and must be suitably impressed) have no access to, or don't bother to consume or understand the site metrics and in many cases don't even have a rudimentary understanding how how their site works (or doesn't work). I've been in so many meetings where the group was ready and willing to kill a feature, or a link or a button and I've had to bring up hard metrics to keep them from killing something that not only people used, but converted more often with a bigger cart. And these are ecommerce sites, so I can only suppose that it is even more so with any site where cold hard cash is not on the line. The trend towards hiding things just to make the design look clean is ignorant and lazy. UX is hard. It should be driven by metrics and validated by observing real user behavior. Anyone who doesn't do that is being vastly overpaid and inevitably eroding the user experience. Nobody should ever have to hover randomly around a screen to hunt for controls, but I see it every single day, and now even on former bastions of usability like core Mac interfaces. How does this stuff get through usability testing? A: It was probably never done, or if it was the aforementioned decision makers never gave it a first let along a second look. Best advice I can give is to never, ever, do a wholesale site redesign when conversion counts. Always incremental, always iterative, always driven by metrics and true usability labs. If someone balks at doing any of this, they shouldn't be in the business, get rid of them or ask for another designer/team.

Karma police Arrest this man He talks in maths He buzzes like a fridge He's like a detuned radio

I went through a cycle of: study ruby -> start using rails -> seems magical -> realize you don't know ruby yet -> study more -> rails no longer feels magical. I suspect this is typical given that there is lot more to ruby than appears on the surface and rails heavily leverages the metaprogramming capabilities.

Baffling that this wasn't a day one feature. Doubly baffling that it now launches on Enterprise only with no guidance on if or when it will be generally available. Never an explanation why this couldn't have been there all along. You have it with the repos already. It almost seems like you would have to go out of your way not to have this baked in from day one. I'm a long term fan, but c'mon github, you're better than this.

I honestly thought they were finally renouncing GitLab flow as a massively misguided idea. They are both flawed. You shouldn't be using branches in your version control system to denote stages in your development process or deployment targets. It totally breaks down when you move to CICD, which should be your goal. Trunk based is the way to go. These git flow things persist because that is what the search engines puke up when people google for git branching.

But what can't be thrown together are truly great content authoring capabilities that support mobile responsive. Those are sophisticated UI heavy features that are hard to do well.

I ran into the same issue a couple of years ago. We had an existing WordPress site. Issues were continuous paving over by consultants resulting in a overweight and fragile site with zero support for true mobile-responsive content authoring. When we discussed our needs with consultants the universal response was to just use WordPress. Clearly Wordpress had frozen this space with their just barely good-enough solution. The other factor at play was the rise of site builder SaaS platforms like SquareSpace and Wix. Their tooling was very slick, but not something you could consider a true development platform, i.e. something that developers and content authors would both consider truly meeting their needs. I liked Locomotive a lot and they used to have a page on their site that really nailed the WordPress shortcomings, but they were in the midst of working on their next major release and we couldn't wait. We ended up going with a cloud based, platform neutral CMS, prismic.io. We got our responsive authoring capabilities and fairly easy integration with our Rails stack. It has worked well. I think our content authors would say they would like more control over the presentation, but I would say that is part of the reason why we like it, because they can't hijack the entire page which inevitably leads to quality issues because the authors are not prepared to test their work in multiple browsers and mobile devices. It also lacks the out of the box blogging structure that WordPress has, but if you are looking for a more versatile publishing capability then it may fit the bill for you. The market has evolved, I'm sure, and I have not kept up with it. I would recommend looking at Locomotive and prismic or other cloud based CMS options but I don't think anything is going to emerge as a dominant CMS platform al la WordPress any time soon, if ever.

Because the Elixir/Phoenix community is largely spawned from the Ruby/Rails community. They are more likely to be continuing to follow what is going on with Rails, even living in both worlds. There are many shared values and experience. That historical affinity is probably why it shows up so much in the same context. The Elixir/Phoenix community is more likely to respect and understand what Rails is and isn't as opposed to the vast majority of pretenders who say they are creating a framework inspired by, or to rival Rails, but really have no clue and proceed to put up something nowhere near the breadth or depth of Rails. Nobody who knows anything is going to come and put up an advocacy post for a PHP framework as an alternative to Rails. They know the Rails community has no interest in going that way. Elixir/Phoenix on the other hand can say with a straight face: we understand Rails and why it is successful and put forward Elixir/Phoenix as a legitimate way forward for those who want to move to a more functional paradigm and the inherent scalability advantages of a Erlang/OTA based foundation.

This not an 'immigrant' thing, it is a H1B requirement. When I initially began working in the US under Trad NAFTA there was no such requirement, but when I changed to a permanent track the job had to be posted. It is part of the process to prove that there is not a qualified person already available to fill the position. The whole underlying proposition of H1B is there is a shortage, disclosing the salary is just part of the process of proving it, which falls to the company making the petition. Really, I never gave it a second thought.

When we get into this type of discusion in our interviews, what we are looking for is not literally are you coding between the hours of 6:00 -11:00 pm. We're trying to find out if are you passionate about software development. If you already have a job where you have the freedom to occasionally explore, or even better utilize, diverse and emerging technologies, then you don't really need to do so 'after hours'. On the other hand, if you've been doing Visual Basic for the last 12 years as your day job, we're going to want to see some tangible indication that you've at least been kicking the tires on some other technologies. If the hiring company literally requires hard evidence of contributions to public repositories, then it probably isn't the place for you (or me) and they are inevitably missing out on some great developers by casting to narrow a net.