eire1130

And this is where we are, a pelican is disputable, but my gun case is indisputable.

If you live in New York state, there are actually some really good programs you can participate in through the IEP process.

We use this. It's much better then bitbucket. We are a distributed team of about 15ish devs. It has had some growing pains, but the support team is top notch and extremely responsive.

I agree with both (1) and (2). We require all devs, as a part of the onboarding process to read, improve and correct the docs for onboarding for each new hire. A PR is required. This forces all developers to understand what happens when something actually breaks and also how to locate the information, should the need arise.

This is also why we've never Dockerized. It masks too many issues and no one seems to have a clear understanding of how all the garments are stitched together.

I have a container garden going in my back patio. I'm up to 31 containers right now.

I would advise to be cautious with cast. It can be powerful and mask bugs if you arent careful (ie, type checker said it's ok, so it must be ok!). You may also want to drop a comment if you use it.

Hello my friendly Georgist

Most people who go on about "the trades", I find, it's unlikely they ever personally worked them. Maybe their Father's. I doubt Marco Rubio has ever touched a hammer, let alone worked as a real laborer.

As for me, going to college was absolutley the thing that really changed my life course.

I grew up on a dairy farm in northern New York. Milked cows until I was 18 and then my dad sold the farm. So I joined the Navy. I did that for 6 years and then when I was about to get out in 2002, I can still remember an officer (you know, a guy with a degree) explaining to me that I was making this huge mistake getting out. Because I was successful in the Navy. Already an E6/FC1. My career was made.

So I asked him, if I'm successful on the inside, what makes you think I cant be successful on the outside? So I got a lot of reasons. It was a good pitch. He even talked to me about getting an associate's at the local college. I was almost there anyway, just a couple classes and I'd be done. At the end, he questioned if Bard, a private liberal arts school I was accepted to, was even accredited.

That's when I knew, not only did he not care, but he would seek to harm my potential future growth just for some metric.

Anyway, so I did go to Bard college. Graduated with a degree in economics, now I'm the CTO / CPO of a middle market company (7 or so years after graduating college).

Had I of stayed, I could have done other blue jobs on the outside someday. I know a guy who works on powerlines in Texas. Says he likes his job. Takes advil like its candy. It pays the bills.

My wife and I have saved a lot, even with two kids. Last year, after our company consummated its sale to a PE company, we've been able to buy our own house in Brooklyn.

If I became a truck driver like my dad did after the sale of the farm, I'm not sure I'd be in the same place today - but it's possible I suppose.

My brother is in the trades. Hes a master plumber and runs his own plumbing company. He's also been successful. His back is also totally shot.

in 1899, probably the only place you could see a passenger pigeon would have been the Cincinnati Zoo.

They were extinct in the wild by 1895.

https://en.wikipedia.org/wiki/Passenger_pigeon

I wanted to respond to this thread in general as someone who runs a team that uses Mercurial for most of our work.

But first, the proposal above, in my view, isn’t core mercurial, which is what most of this discussion is centered around. This is mercurial with evolve + topics, which has differences to what many of you are familiar with.

With evolve + topics, many of the critiques of mercurial go away:

  * Light weight branches for short development
  * Ability to squash / fold - mutability
  * Ability to rebase - mutability

With this class of features, you get the major product differentiator that git offers (light weight branches that are simple for collaboration). Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops.

That is why this proposal is important and stands out from bitbuckets offering. Bitbucket (For now) only offers first class evolve support (in beta).

With that said, we use mercurial in production for our main repository. We do use evolve + topics for our development and when commits land in production, those commits become “immutable”. Topics were very much a game changer for us when we started using them about a year ago. We had previously used bookmarks for collaboration and that situation wasn’t really viable.

Like most people reading this here, our development team targets mostly web development. Most of our dev lives in one repo and generally we target a deploy per day, or multiple per day. We aren’t “continuous delivery”, but we are “effectively” “continuous delivery”.

We have a straight forward workflow. We have a Topic per Jira ticket. That Topic gets cut from the head of the branch “default”. Developers work in these "feature branch" through the features lifecycle, sometimes these are big things (multiple week - big changes) and sometimes small things (hours or days worth of work). Developers can rebase their work, if they wish, and they can squash, if they wish. I generally discourage the later as I’m a believer more commits the merrier. I’m also not allergic to merging and I don’t see the value in a purely linear history, so rebasing isn’t as common for us. We also have a single integration branch. When developers are ready, we merge to this branch and the ticket gets advanced to qa. Once the ticket passes qa, we merge to default (therefore advancing the head) and the topic is closed out on its own.

So with the above as a brief overview of our process and workflow, I wanted to also talk about some of the pain points that mercurial has. Some of these aren’t necessarily caused by mercurial directly, and some aren’t even addressable (ie, if we were to switch to git, we’d have the same problems, or similar)

Pain Points:

  * Tooling kind of sucks. The biggest argument now to use git is less git itself, and more that you are buying into an ecosystem. As an example, we use Buildkite for our CI. Getting this started required some hacking to make it work. Buildkite doesn’t “just work” with HG. That’s generally the tooling story. We can make some stuff work, but most stuff doesn’t “just work”.
  * Merges can occasionally still be painful in a collaborative environment when multiple devs are touching the same files and the same line numbers. I think this is an unsolved problem and probably will remain so until the universe cools to absolute zero.
  * Evolve is great and I use it all the time, but some of developers here complain that it isn’t as well documented as other pieces of mercurial.

Benefits:

  * In my view, the UI is simpler. Our team is comprised of individuals of varying degrees of technical sophistication. For examples, our designers are not software engineers and don’t really need to understand what a DAG is. But they do need to commit directly to our repository, create topics without asking others, and really only ask for help when they did something wrong / got themselves in trouble
  * TortoiseHG. This is a great tool, and most people can get benefit from it. It has some support for topics.
  * All commits are kept for all time. Not everyone finds this valuable. I find this extremely valuable. Evolve handles the mutability question by “hiding” old commits and basically creating new ones.
  * Hg log, which was mentioned before as a burden, in my view is a huge benefit and feature. Most hg commands take a revset.

Or just use evolve + topics and you can squash/fold in pretty much the same way as git, plus you hg obslog you can still reference the root commits.

I strongly dislike the mac OS. I only use the system because a.) Duel booting systems are a real pita (oh, let me boost to windows so I can look at that spreadsheet in a excel). And b.) Macs are powerful and light. I spend 1hr plus on the subway, so that's important.

If windows had a sensible terminal environment and real package manager and i could use that, great. And not some hacky workaround. And no, powershell is not sensible.

I do like mint and ubuntu, but office productivity software is on linux terrible on linux envs imo.

It was prior to the Oracle purchase, I believe.

MySQL was the M in the LAMP stack, and was installed on many linux distros by default.

I'll be honest, if anyone asked me to write a FizzBuzz style test, I would just walk out on the spot.

I bought a copy.

I think unless your Netflix, jpmorgan card services, or something else equally large this approach is a mistake.

To me, the main benefit of the polyglot SOA paradigm is: we simply just can't find enough talent located in y skilled in x.

Most services complain of complexity from "the monolith" but upon further inspection, what we're usually see is poor architectural layout. These teams feel that microservices solve this, but really just make the entire backend more complicated.

The same can usually be achieved through enforcement of an API contract and good leadership rather then TLS handshakes.

* Unclear business model * "Complex tech stack" for a photo sharing site * Building a product against something that has been tried many times, and failed each time (crowdsourced brand identity) * Unpaid "internships" studying under other junior developers * Probably solving for a problem that doesn't exist (see point 3 above)

Man, where do I sign up!

Sure, but I think this is what the author is getting at:

  >>> class A:
  ...     def __a(self,b):
  ...         return b
  ...
  >>> A()
  <__main__.A object at 0x0000024EE5B0EBE0>
  >>> A().__a('b')
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  AttributeError: 'A' object has no attribute '__a'
  >>> a=A()
  >>> dir(a)
  ['_A__a', '__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', 
  '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', 
  '__sizeof__', '__str__', '__subclasshook__', '__weakref__']
  >>> a._A__a("b")
  'b'

In practice, I have never seen this used and just confuses things - and for dev's coming from Java / C++ or some other language it tends to just confuse things.

It's really not that hard to "do the right thing." Yet they have to go out their way to be dicks about it.

if anyone knows someone who has purchased an infected lenova with superfish, send me an email. My wife is a class action attorney and is conducting an investigation in the matter. Eire1130 (at) gmail (Dot) com