-
Nearly all users of version control are non-developers.
Citation needed.
-
I didn’t read this novel, but I do think systems like SVN are under-appreciated.
At one point I set up a dropbox like system for completely non-technical employees to use. They just had to edit their documents in
MS-{word,powerpoint,excel}, hit save, and then hit sync or whatever in TortoiseSVN and I basically never got any “I deleted everything, what is a staging area? omg I am freaking out right now” sort of support requests. The system never degraded when they accidentally committed massive files to the repo and then went “oops” and deleted them.Good experiences had by all. Git would not have worked.
-
-
Out of genuine curiosity, do you have recommendations for a good document store that does versioning?
I’ve committed stuff in Git because it’s only been me caring about said stuff, and also sync things with ownCloud, but there could be something better, esp. wrt versioning and non-geeks.
-
-
-
-
I think the closer financial construct is a toxic asset.
-
agreed. toxic assets or perhaps investments that are operating at a loss. because the software actually takes money away from you, it’s not like the money is “in purgatory”, it’s being siphoned away. it’s more like a house or some other physical property that is vacant, and huge, and thus costs a lot of money each month just to keep up without foreclosure.
-
-
Just git?
I was kind of hoping that if we’re going to break the github hegemony, we might also start to reconsider git at least a little. Mercurial has so many good ideas worth spreading, like templates (DSL for formatting the output of every command), revsets (DSL for querying commits), filesets (DSL for querying files and path) and changeset evolution (meta-graph of commit rewriting).
-
Don’t forget pijul!
Seriously, though, I don’t think there is any “github plus something” that is going to break the github hegemony. Github won because it offered easy forking while Sourceforge was locked in a centralized model. Sourceforge won because it was so much easier than hosting your own repo + mailing list.
The thing that will get people away from github has to have a new idea, a new use case that isn’t being met by github right now, and which hasn’t been proposed before. That means that adding hg won’t do it – not because hg is worse than git (honestly, git’s terrible, and hg is fine), but because hg’s already been an option and people aren’t using it.
Adding email commits won’t do it, because that use case has been available for a long time (as pointed out elsewhere in these comments) and people aren’t using it.
Until something new is brought to the table, it’s all “let’s enter a dominated market with a slight improvement over the dominant tech”, and that’s just not going to be enough.
-
So, one thing that I would use a new contender for is being able to put my work under my own domain.
The “new thing” here is “have your personal branding on your site” (which is clearly fairly popular given how common personal domain/sites are among developers).
If I could CNAME
code.daniel.heath.ccto your host to get my own github, I’d do it today (as long as any issues/wiki/PR state/etc remained usefully portable).-
-
-
I don’t mean corporate/design branding.
I want to use my own name (and be able to move providers without breaking links).
-
-
Yep - so it has to be oss too.
-
That makes sense actually. sr.ht supporting the ability to use your own domain name (presumably a subdomain of your personal domain name for personal projects?) would make it really easy to migrate away from sr.ht in the future if you felt it was more cost-effective to host your own. Although I don’t know what the pricing model is intended to be.
-
-
-
-
-
You can do that with Gitlab (or Gitea if you prefer something lightweight). Only thing is you need to take care of the hosting yourself. But I’m sure there are companies offering a one-click setup, to which you can later point your own domain.
-
If you host your own gitlab instance, can you fork and submit patches to a project that’s hosted on gitlab,com, as easily/seamlessly as if you were hosted there?
Centralization has benefits that self-hosting can’t always provide. If there were some federation which allowed self-hosting to integrate with central and other self-hosting sites, that seems like a new and interesting feature.
-
Git is already federated with email - it’s specific services like GitHub which are incompatible with git’s federation model (awfully conveniently, I might add). sr.ht is going to be designed to accomodate git’s email features, both for incoming and outgoing communication, so you’ll be able to communicate easily between sr.ht instances (or sr.ht and other services like patchworks or LKML).
-
-
The gitlab, gitea, and gogs developers are working on this but it’s still very much in the discussion stage at this point. https://github.com/git-federation/gitpub/
-
Oh, definitely no federation. Didn’t know that federation was what he was looking for.
-
-
-
It’s currently awkward to run multiple domains on most OSS servers which might otherwise be suitable.
-
-
-
-
-
I’m afraid you’re not going to find a sympathetic ear in sr.ht. I am deeply fond of git and deeply critical of hg.
The GitHug hegemony has nothing to do with its basis on git. If git were the product of GitHub, I might agree, but it’s not. If you really want to break the GitHub hegemony you should know well enough to throw your lot in with the winning tool rather than try to disrupt two things at once.
-
-
-
The GitHug hegemony has nothing to do with its basis on git.
Exactly; it’s the other way around. Git got popular because of github.
Git was much worse before github made it popular. It’s bad now and difficult to use now, but it was much worse before 2008. So if you just want to get away from Github, there’s no need to stay particulary enamoured with git either.
And whatever criticisms you may have about hg, you have to also consider that it has good ideas (those DSLs above are great). Those ideas are worth spreading, and git for a long time has tried to absorb some of them and hasn’t succeeded.
-
-
-
tubbo
2 months ago
|
link
| on:
Office 365, Skype, MS Teams, and VS Code are all being rewritten in React Native
I was wondering why Microsoft was so interested in JavaScript as of late. All I have to say is that I hope the React Native ecosystem explodes because of this. It’s a great little framework for building mobile apps, but I’d really like to see more desktop support. The react-native-macos project does a good job at forking react-native to support macOS at least, but it’s kinda cumbersome to get started with.
Hopefully MS will open-source the code they used to make this stuff work on the desktop with React. I’d love to see it and help move it forward!
-
I’m sorry I don’t understand what this is. What would I do with this? Is this similar to like Electron?
-
-
-
because of the way it’s designed, as described in the talk. changing that would break way too much stuff, like libs which rely on linking to C in order to function.
one cool thing about Deno is that it seems like one could make a “codepen”-style JS code pasting/collaboration service really quickly, and not have to worry about sandboxing the code execution like you normally have to do. the fact that its package management works by using URLs makes it even easier. just
import React from "https://unkpkg.com/react-0.0.1/react.js"and you’re done. no messing around with package managers, no worrying whether it’s down, no worrying about depending on “yet another package ecosystem” if you’re coming from other places like Python or Ruby.
-
-
-
I pointed at a nearby engineer and said “Don’t you have an MMU and process isolation on the iPhone now?” He had a wide eyed look of don’t-bring-me-into-this, but I eventually got a “yes” out of him.
Jeez John, really putting people on the spot with that one.
-
this is pretty awesome, the distorted quality of the vocals sounds amazing to my ears =)
-
w0rd
-
lol this is amazing happy april fools day
-
It seems very difficult now to encourage potential contributors into learning a new source control manager AND a new forge for every project they want to contribute. Which was a basic requirement a few years ago.
Are we really trying to return to that time? It was frustrating and confusing to download open-source projects from SF let alone actually contribute back to them. It’s easy to correlate the explosion in open-source interest and development, especially by companies, to GitHub’s initial hockey-stick growth of users.
-
Is it still “unpaid overtime” if most of my open-source contributions are for problems I’ve solved for myself, rather than those I’ve solved for a company?
I guess it’s technically unpaid work for my own project, but so is everything else on my own projects. Programming was a hobby for me until I started working professionally, so there’s lots of code up there that I just wrote because I wanted to or because I needed to. A person with a previous passion in programming, to the point that they feel comfortable releasing their code, seems like a legitimate candidate for a company who believes open-source contributors are the “best of the best” in their field.
Whether that is true or not is an argument somewhat out of scope for this comment, but I personally enjoy working with people who have previous experience contributing open-source code, and it really has nothing to do with what they look like. People who manage OSS projects are familiar with concepts like pull requests, proper branching techniques, and typically are very good with Git. At my company, we use Git but it’s a challenge sometimes to get my co-workers up to speed with the way we should be running our projects. On that factor alone, I feel that a dev hire who has prior experience managing projects like this is a major win for our team.
At the same time, I do feel that you’re doing yourself a disservice whenever you draw a line in the sand like that…“we will only accept open-source contributors”, “we will only accept programmers who have prior testing experience”, etc. Unless they are preventing us from seeing things we need to see before an interview (such as code samples from previous jobs), there should be nothing that precludes us from at least having a meeting and talking with the guy (or girl).
-
Is it still “unpaid overtime” if most of my open-source contributions are for problems I’ve solved for myself, rather than those I’ve solved for a company?
Yes, if it’s expected that you work on things outside of work and you don’t get paid for them, I’ll class that as unpaid overtime.
Whether that is true or not is an argument somewhat out of scope for this comment, but I personally enjoy working with people who have previous experience contributing open-source code, and it really has nothing to do with what they look like.
Sadly, it does have to do with what they look like.
If you’re choosing to hire using open-source experience, you’re biasing to people who look like men because people who look like women are even more underrepresented in open-source than just the software industry itself (like 25x less represented).
Sure, you’re not directly choosing to hire men, just indirectly preferring them.
At my company, we use Git but it’s a challenge sometimes to get my co-workers up to speed with the way we should be running our projects.
Try to be more direct. Hire people with Git experience, not out-of-work GitHub experience.
At the same time, I do feel that you’re doing yourself a disservice whenever you draw a line in the sand like that…
It doesn’t even have to be a line in the sand. Many people use it as a multiplier, giving people advantages just because they have spare time outside of work. That has nothing to do with them being a good employee.
Truth is that looking at GitHub is very easy. Hiring is usually difficult. Hiring based on GitHub makes hiring easy by sacrificing the size and diversity of the hiring pool. Not a good solution, right?
-
It doesn’t even have to be a line in the sand. Many people use it as a multiplier, giving people advantages just because they have spare time outside of work. That has nothing to do with them being a good employee.
Truth is that looking at GitHub is very easy. Hiring is usually difficult. Hiring based on GitHub makes hiring easy by sacrificing the size and diversity of the hiring pool. Not a good solution, right?
I think we can both agree on the fact that basing your hiring based on a single factor, GitHub or anything else really, is a practice that has proved its idiocy time and time again. That said, I don’t find anything wrong with noting open-source code as a “+1” when hiring. I don’t think it should be the only reason why a company hires programmers, but I do think it should be a valid practice to consider open-source contributions in a hiring decision.
edit:
Yes, if it’s expected that you work on things outside of work and you don’t get paid for them
Judging by my coworkers contributions to open-source in almost all of the companies I’ve worked for (most of them have done no such thing), I would say it’s not really an expectation but is definitely a good thing to have on your resume.
-
-
-
I always thought this would be neat but then I realize how much I move around with the laptop every day…and close my tab. :)
For stationary programmers (not programmers of stationary, programmers who are…you know what I mean!), I feel like this is a golden ticket.
-
Also, this was supposedly the service that Edward Snowden used.
-
-
For more on the subject of when comments are good and when they are bad, I recommend Clean Code chapter 4 “Comments”. You can read it starting on page 86 of the book PDF.
The chapter, like the article, concludes that comments are usually bad. It also shows various examples of good and bad comments.
-
I personally think this is why comments are “greyed out” in many text editors. When I write comments, it’s typically to write documentation for the code, to be read in a browser or something. Just so people don’t have to read the actual source to figure out how to use my library. So I’d prefer it if my editor greyed out comments, because they frankly have no place in my code but rather as documentation for my code. Therefore, I don’t want them to cloud my vision of what I really need to see.
-
Usually documentation generators only read block comments, so it would be possible to grey those out and keep inline comments in a more prominent colour. Although I guess this won’t work for languages like Ruby where people tend to use inline comments for everything.
-
Unfortunately, RDoc in Ruby reads inline comments, so I’m stuck with that. But then again, if you’re doing it right you shouldn’t need comments in Ruby :-P (j/k)
Vim has a nice feature wherein if you write “TODO:” or “NOTE:”, it’ll highlight the word in purple. So sometimes I will leave NOTEs for other devs. In a Rails app, you can read all your todos by running
rake notes. Super useful, hardly anyone knows about it :)
-
-
-
-
I guess if “lost its values”, this guy means “continue to serve the people rather than business interests”, then yes?
One thing that’s always remained respectable about Mozilla as an organization is its commitment to listening to its users, even to a fault. Sometimes I think there could have been more scrutiny over the design decisions and features implemented in Firefox or Thunderbird, as I’d much rather use fully open-source software than software made to sell more computers/phones or boost advertising value. It just makes me less anxious about the true intentions behind new features (especially ones that want more and more of my data…). But unfortunately, I don’t find Firefox or Thunderbird to be superior to their proprietary alternatives Safari (I use WebKit nightly as my primary browser) and Apple Mail. There are many reasons for this, but I don’t feel like listing them here.
Certainly, there are very few sites who REQUIRE third-party cookies to function, and those can be easily whitelisted. For the vast majority of us, third party cookies are annoying and unnecessary, and if you’re smart enough it’s easy to turn them off. And many people do just that.
— looks at AdBlock Plus running in the corner of the browser… —
-
Lockitron is way cooler. https://lockitron.com/
It’s even based on open-source hardware so you can open up the device and have other devices open your door rather than just your iPhone.
-
This is beautiful.
-
-
We’ve been debating this on the Diaspora loomio…we’ve come to the general consensus that Persona is not a scalable solution for persistently logged-in user accounts. But a public site like HN might benefit from it, because they wouldn’t need to keep track of passwords (and hash them, keep up to date w/security, etc.) anymore.
Also, I really like how Github has Basic HTTP auth with your API key and username, as well as OAuth capabilities.
-
-
haven’t posted in a while but it is http://psychedeli.ca