n0us

I use I use imap jj <ESC>

Traitor.

none but I wouldn't call it a more reliable source than quora for something like this.

"In British English, either is acceptable"

from the first sentence.

> Quora

> not a high quality reference

> proceeds to reference Wikipedia

No it's not a joke and yes it's valid grammar. If you're going to correct someone's grammar, at least know what you're talking about.

https://www.quora.com/Which-one-is-correct-a-history-or-an-h...

No, there is no simple command to remove old images because the creators of docker want you to compose other existing commands to delete them and it would be unnecessary to add a command. IMO this is a terrible decision but that was apparently the rationalization.

Heard they're going to remove it in the next version, as well as hdmi. A USB dongle will be required to connect to your TV and internet is wireless only /s

not sure about deaf-mute people but https://en.wikipedia.org/wiki/Prosopagnosia is an area of interest for people who study philosophy of mind

What makes you certain that the world's best search engine is not falling for that?

But then you wouldn't have to buy another one.

Muster | Washington, DC | Northern Virginia | Richmond, Virginia | Full Time | Remote or Onsite depending on proximity to Richmond

https://muster.workable.com/

http://www.muster.com/home

About Muster

Muster is an advocacy platform that enables professional associations and nonprofits to engage their membership in the legislative process. By providing simple and intelligent solutions to communicate with lawmakers, client organizations are able to easily influence public policy and advance their cause. Muster has a proven track record in powering the campaigns behind legislative victories and increasing membership-driven advocacy.

Job Description:

Skills & Requirements While we are seeking someone who covers all the requirements below we would also like to speak with anyone who has a nice combination of the below skill set even if you are missing one or two items.

* Experience with Python/Django

* Experience with ReactJS or other single page application frameworks

* Experience with AWS, Heroku or other cloud-based infrastructure providers

* Experience with git and Github

* Experience with Docker or other containerization software

* Experience developing REST APIs

Junior - Senior Level

Competitive salary based on experience

Work with an exciting and energetic team in an attractive downtown RVA office space [with free parking!]

Stock options for employees

Paid holidays and vacation

Don't hate the player, hate the game.

As the person who wrote the top comment in the thread that you link to, I will admit: You are right for the most part. The choice to use an unproven library is my fault as it was my choice and it is also my responsibility to deal with the consequences and costs of the instability. This is why I will be removing React Router from my project as soon as I can find a stable and suitable replacement.

Recognizing the responsibility for your own actions does not preclude you from being frustrated and at times outright angry at the outcomes of those actions. In this case I (wrongly) assumed that after a 1.0 release the library would be relatively stable and have been repeatedly duped into believing that this time the major version release would be the stable one. I don't really see anywhere that people were issuing an outcry for V4, so I am still confused as to why it was so urgent to release it. It wasn't perfect but it was fine. Unfortunately in my frustration and confusion I chose to write a very strongly worded comment that apparently some people did not like.

> To be clear: developers that release libraries and then iterate the API in public do not deserve personal scorn for doing so

I have never gotten the impression that react-router was someone's personal library, rather it is a community project that is maintained by notable members of the javascript community and it is my belief that delivering half-baked stuff to the people who counted on them, and who they led to believe could count on them, is not a fair thing to do. I don't believe it is unreasonable to be frustrated with fickle leadership from people who stepped up to lead the project. If they can't deal with the criticism or don't have the time/effort/inclination/whatever to lead in a way that is agreeable to most of the community then perhaps someone else could lead. When projects have thousands of stars on github, making rapid successions of breaking changes throws all of those people for a loop.

If you do in fact view the repo as your personal project and want to make huge changes all the time, like every 6 months, I don't think that the version with thousands of stars is really the place to do that. Why not just do it on your own where it isn't going to affect so many people.

Note: Neither this, nor my original comment should be taken as personal attacks on the maintainers although I am aware that both are probably over stated. I'm sure they are all extremely talented developers and kind people.

“Sharper Image is the last company in the whole country I would have allowed him to even speak with,” Kaufman said. “We all know their reputation. They went bankrupt. Their name makes you think of a niche item that costs a lot of money, and that’s not what Nubrella is.”

A 60 dollar sunshade strapped to a hat isn't niche?

> I've watched React Router grow from one-of-a-handful-of-experimental-routers-for-React-on-GitHub to the most well-known third-party library in the React ecosystem

> Libraries that experiment with their APIs, like React Router and React Motion, help all of us understand how to wield React better

If I read this correctly, you believe that it is still in experimental phase? I don't have any problem with people learning and experimenting, but using major release versions a your petri dish is obnoxious for all the thousands of people using react-router even if it is convenient for the core maintainers. There is a difference between an upgrade and an overhaul, with the extent of the changes over V2,3,4 they might as well have just released a completely new routing library or just maintained an experimental branch to figure out what actually works before releasing a series of major breaking changes in quick succession to the greater world. I'm aware that breaking changes are necessary sometimes, but rapid churn is not necessary, esp once you are post 1.0 release. If there were some burning reason to release an upgrade then that would make sense but this release does not even address some of my major pain points with the API.

I also am not complaining about the cost and personally I don't see any validity in the "it's free so I am beyond reproach" mentality that open source people seem to have. What makes you think that I would thank someone for something that was free even if I didn't want it? Or that anyone would for that matter. Thanking people regardless of what they did, just because they did it for free, is one way to erase market signals which govern the direction of open source projects. I would rather just be candid and honest so that maybe people will remember that me and other devs in general are negatively impacted by breaking changes and therefore will consider keeping projects stable.

I also didn't "try to embarrass the creators" and the only person on here to made this personal was you, who decided to name the maintainers by first name.

python/ruby/java on backend. React/Ember/Angular on front end. The core libraries are relatively stable, it's mostly supporting libs that will burn you if you aren't careful.

One of my favorite articles. Also another argument for why we need a boring, stable, un-opinionated, cross framework compatible routing library.

There's a big difference between breaking changes which resolve real pain points in a language/framework/library, like the break between python 2 and 3 and changes that are just for the fun of it, because someone "felt like it was better". I like to view developing software as an investment. You are spending time and money outright, and there is an implicit cost in foregoing other opportunities when you make a technical choice.

Investing in react-router is like investing in a clown. It's a total toss-up. The maintainers could all move on to whatever other hip lib and finally it will be stable, or you can continue betting large sums of money on what is basically a coin flip every 6 months: Are they going to screw with the library again (yes) and will it cause a bunch of bugs in my program (probably). It's a bad investment, esp if you try to upgrade. The ironic part of this is that honestly I feel like the V1 API is the best out of all of them. If they had just iterated and brought breaking changes that were actually needed instead of just those that they felt might be fun, the project would be much better for it in my opinion.

(I know python <-> react-router comparison is apples to oranges but bear with me)

I normally try to keep comments here reasoned and civil but the amount of churn in this library is almost so much of a joke that it should become a meme. At this point it's almost more expensive for me to continue updating than it would be to just fork the library and maintain the upgrades myself.

Any time I have to touch react-router I just resign the idea that I'm going to have to take at minimum a day to work out the bugs that pop up with every upgrade, (even minor changes).

> Why the huge change? (AGAIN?!)

> tl;dr Declarative Composability

The huge change is because the maintainers are apparently unwilling or incapable of either A. Creating something good enough on the first, second, or third attempt, or B. are completely oblivious to the needs of devs trying to create practical software and don't understand that project stability is just as important as a good API.

Thanks but no thanks.

Muster | Richmond, Va | Full Time | On Site

https://muster.workable.com/

http://www.muster.com/home

About Muster

Muster is an advocacy platform that enables professional associations and nonprofits to engage their membership in the legislative process. By providing simple and intelligent solutions to communicate with lawmakers, client organizations are able to easily influence public policy and advance their cause. Muster has a proven track record in powering the campaigns behind legislative victories and increasing membership-driven advocacy.

Job Description:

Skills & Requirements While we are seeking someone who covers all the requirements below we would also like to speak with anyone who has a nice combination of the below skill set even if you are missing one or two items.

* Experience with Python/Django

* Experience with ReactJS or other single page application frameworks

* Experience with AWS, Heroku or other cloud-based infrastructure providers

* Experience with git and Github

* Experience with Docker or other containerization software

* Experience developing REST APIs

Junior - Senior Level

Competitive salary based on experience

Work with an exciting and energetic team in an attractive downtown RVA office space [with free parking!]

Stock options for employees

Paid holidays and vacation

FYI check the promotions tab in Gmail if you're missing the email.

This is nice but it's characteristic of most other Docker tutorials which say "just run this command" and don't bother to go into how or why it works. As a result, all the reader can do is copy and paste (if the command even works in the first place or the tutorial isn't out dated). What I think most people need to know is how they can do this but modify the app to work for their purposes instead of just "hello world".

To continue with the analogy one might say that Django comes with the molds but you have to know how to use the furnace and how to make the bricks without them turning out crappy. Much greater potential because you can make whatever you want but also higher barriers to entry.

To be fair, Django doesn't make you adhere to that pattern and you can use Django any way you please. Django has a lot more "in the box" than Flask and I will agree that I think it's more difficult to get started with.

Richmond, VA.

Sorry, new to this.

Muster -- Python/JavaScript, ONSITE Richmond, VA

http://www.muster.com

https://muster.workable.com

About Muster

Muster is an advocacy platform that enables professional associations and nonprofits to engage their membership in the legislative process. By providing simple and intelligent solutions to communicate with lawmakers, client organizations are able to easily influence public policy and advance their cause. Muster has a proven track record in powering the campaigns behind legislative victories and increasing membership-driven advocacy.

Job Description == Web Developer

Skills & Requirements While we are seeking someone who covers all the requirements below we would also like to speak with anyone who has a nice combination of the below skill set even if you are missing one or two items.

* Experience with Python/Django

* Experience with AWS, Heroku or other cloud-based infrastructure providers

* Experience with git and Github

* Experience with ReactJS or other single page application frameworks

* Experience with Docker or other containerization software

* Experience developing REST APIs

Couldn't have said it better. In the webdev world this turns into a problem because I need to rely on these oss projects and while some of them might be high quality, there is a significant overhead involved in determining which ones are worth using and which ones I can rely on. For personal projects it's a not big deal but for work I want to be as efficient and reliable as possible and the chaotic/flaky ecosystem gets in the way.

edit: fixed to *not a big deal

One factor that leads to fragmentation is this "theme" that I seem to see over and over that when a project is popular the creator gets to be the github maintainer and take credit for it's success as a large and popular project, which by itself is a good thing.

The bad part is that when the maintainers make unpopular decisions like disabling all functionality by default and relying on submodules, or not wanting to fix some obviously horrible bug because it's a 'feature', or abandoning the project for months at a time, often there is a cop out mentality that goes along the lines of "well it's my project and I didn't guarantee anything when you decided to use it so why don't you go make your own." There by taking credit for the project's successes but not responsibility for it's failures. So then people do go and write their own implementations and we end up with half a dozen half baked libraries.

An Example: Underscore and lodash are both very good, so are not examples of half-baked, but do we really need both of them? People will just say "well you only have to use one in your app... yada yada yada" but the problem is that if I want to rely on any other npm packages in my app, are they using lodash or underscore? I'll probably just end up with both of them shipping in the bundle because for whatever reason there couldn't just be one popular utility library, there had to be two that do basically the same thing. People will respond to this and say "well why don't you fork those modules that rely on underscore and make them use lodash?" My answer is no. I don't want to fork stuff. I just want to be able to find modules that I can rely on with a reasonable expectation of quality and maintenance. I'll even help maintain if it doesn't seem completely futile.

There may be some advantages of lodash over underscore in comparison to one another but those advantages are minor in comparison to what would be gained by having a single utility library that everyone is on board with.

Don't even get me started with routing libraries for React.

You can never fire the AI because without it the whole place would burn down and nobody else understands how the code works.

I personally moved all my projects away from mixins a while ago when I first heard they were deprecated. At first I was frustrated because of JS churn but this certainly was the right move.

For anyone who is apprehensive, the shift in thinking from using mixins to HOCs was not so difficult even if it's initially puzzling.

Quick edit: forgot to mention that this shift made my code way easier to understand in some places and thus the initial investment saves dev time in the long run.

Well that answers it. If I can get the app to work long enough to reach level 5 I'll try that.

It's a good thing they decided not to include that information from the start. They wouldn't want people to think there might actually be something fun to do.