As a long-time MUI user myself, I had the same "revelation" about Tailwind recently. Before MUI, I worked at a couple startups where we came up with our CSS franken-framework with homegrown utility classes.
It's just easier to do fast proto-typing with various Tailwind classes, and then refactor common sets of HTML tags with tailwind classes, they become reusable React (or Svelte) components.
Indeed. Anecdote: Several years ago I worked on a U.S. GOSS (Government Open-Source Software) project that was a web app that allowed different apps running on different domains to function as "widgets" and allowed cross-domain communication between these apps in a drag-and-drop window environment in the browser. The intention was small apps could be composed into larger apps by allowing them to communicate with each other in this environment.
It supported multiple browsers, including IE7 in as late as summer 2014, because end-users in the U.S. Navy had machines that only had IE7. Countless man-hours (and U.S. taxpayer dollars) were spent to ensure all features worked in IE7, including drag-and-drop and responsive UI.
That project was the single biggest driver for me to get the hell out of the government contracting world and into the "truly" private sector. At least at a startup I can say more or less "if it works in Chrome, it works."
That's definitely a viable option for biking around a city that doesn't have favorable spring or summer weather. Can you store your bike inside instead of locking it up on the street? I imagine an e-bike would be at greater risk of theft than a regular bike. That might be an issue for folks who commute by bike but have to lock it up outside.
Yea, I lock my bike inside the office (where I charge it as well). I also keep it in the garage. Additionally, I have a GPS on it, so if it does get stolen, it's a lot easier to locate
Regarding commuting via bicycle: it's not necessarily a problem with traffic, as more with weather. Also it's wrong to compare a single city, Amsterdam, with a bunch of American cities because of drastically different weather patterns in those cities.
Amsterdam has average temps (in F) from the mid 30's to the mid 60's[0]. That's prime bike weather. That's pretty much in line with San Francisco, which is a good city for biking. Even Manhattan and Brooklyn have reasonably overall pleasant weather for biking.
But compare SF to somewhere like Washington, DC, or Austin, TX. For 3-4 months of the year, DC feels like a swamp. Same with Austin. It's much more preferable to use public transit or drive than bike in that weather.
While the weather may be comparable, San Francisco is a very hilly city. I imagine that Amsterdam is relatively flat. In spite of its problematic, yet aesthetically pleasing topology, there is a strong culture of biking in SF.
Sure, the US climate is diverse, and it makes sense to use the appropriate transportation method for that climate. That doesn't negate the fact that "just keep using cars" is a bad idea.
I think a majority of the motor vehicles are taxis, buses, private car services, and what does the most damage per vehicle - commercial vehicles. Box trucks take a much greater toll on roads than a bunch of average passenger cars.
For at least a few years now, even conventional "slushbox" automatics get better mileage than a manual transmission when in the same car.
Lower maintenance costs are usually mentioned as an advantage of manual over automatic, but slushboxes have been around for quite a while now. With routine maintenance and average use (meaning no launch control usage or burnouts), both types will last forever.
You can drive a manual very efficiently. My Forester has a display showing instantaneous efficiency. I can increase mileage by a third by paying close attention to it. But that means driving very conservatively, which I'd never do without the display to remind me.
It's not awkward, and it's totally your prerogative for telling a recruiter for that. If they say "well I won't work with you if you won't disclose that info", then I'd say "thanks for your time, good luck in your search." Nowadays there's always a dozen other recruiters who'd be willing to have a phone call with a developer who's actively looking. Obviously, YMMV.
As a rule, I don't tell third-parties (recruiters, etc) my current or former compensation. I ask what range the company is aiming for, and whether I'm interested or not. I think compensation is something to be discussed only between the candidate and the company.
Anecdotal story: I once was lowballed without my knowledge going into an interview set up by a third-party recruiter, contracted out by the company. They were very excited to get me in - turns out the recruiter gave the company a number that was 25% less my current salary. The company wouldn't be able to meet anywhere near my actual current salary, but the recruiter wanted to get a butt in the seat by any means.
From now on, I keep that info private until I choose to disclose it.
1) The language was created by a researcher (Guido Van Rossum) at a research facility in the Netherlands [1]
2) Network effect - as more machine learning researchers and engineers in academia used it, the need for a language that could integrate with FORTRAN with similar performance came about, which lead to NumPy, SciPy, etc.
3) The language itself is pretty simple to grasp. There's multiple ways in Ruby itself to do something, while in Python there's at most one way to do something. Anecdotal - a lot of researchers I've worked with care more about the usability and ease of adoption of a language, compared to the expressivity.
Not disagreeing with the relative simplicity of Python compared to Ruby, but the degree to which the Python community is adamant that there is always only one way to do something has always baffled me. What about `map` versus a list comprehension, or `glob` vs `os.path`? Obviously Python has pretty clear standards about what the correct way to do something in the language is, but I feel like the persistent claim that there's always exactly one way to do something can range from oversimplified, misleading, or just plain wrong.
Extreme pro-Python statements about "one way to do it" are usually made by relative newcomers who are caught up in their enthusiasm for purity. (This exuberance is natural, and is a big part of the language adoption cycle.) Extreme anti-Python statements about "one way to do it" are usually made by outsiders viewing Python through accounts given by enthusiastic newcomers. This exuberant-newcomers-vs-skeptical-outsiders dichotomy isn't representative of the actual Python culture, which is much more sensible and practical than all of this implies. If you go to PyCon and attend talks by long-time Python folks, you won't find them advocating anything like blind adherence to "one way to do it".
To get specific, the wording in PEP 20 is: "there should be one, and preferably only one, obvious way to do it". Note that the dominant idea here is that there should exist some obvious way. It's merely preferable that there be only one way. Again: this is sensible, but it's not good fodder for newcomers craving purity, or for detractors craving straw men.
PEP 20 itself is often elevated to religious levels of importance, as if it were a design document that served as a blueprint for the design of Python. It's absolutely not that; it was written by Tim Peters (not Guido!) fully eight years after Python's first release. Here's the original email that Tim sent to comp.lang.python on 4 June, 1999: https://groups.google.com/d/msg/comp.lang.python/B_VxeTBClM0.... Note how he finishes: "If the answer to any Python design issue isn't obvious after reading those -- well, I just give up <wink>." Tim is very particular about his winks, and that's not even a <0.5 wink> or a <0.9 wink>, but a full, unqualified <wink>.
To put all of those pieces together: (1) we have a short, tongue-in-cheek document written after-the-fact. (2) It's misinterpreted as a design document for an entire language and ecosystem. (3) A secondary portion of one of its points is misinterpreted to be the entirety of the point. (4) This is done by exuberant newcomers and skeptical detractors who don't accurately represent the Python culture as a whole. This is why you get the impression that the community is adamant about "one way to do it". It's a reasonable extrapolation from the visible evidence, but it's not true.
pure speculation, because i don't know the interior history of python:
1. perl has always prided itself that "there's more than one way to do it" including repeated, prominent use of an acronym for that. see timtowtdi.
2. there is a theoretical idea kicking around out there that, if a language allowed for only one way to express any idea, then that language would be a better language (all else being equal) because if you and I always write the same code for the same task, we could easily maintain each other's work. see for example "egoless programming" or the ideas that led to Simonyi's "metaprogramming" (whether or not you agree)
3. perl is a mess
therefore, it might, given the history, make sense to say that about python as a way of trying to point out a salient difference from perl
I've never seen that sort of response from the Python community. I've seen plenty of discussion and recommendation about what is "Pythonic", but never about there being "one way to do it". If anything, python is touted as being able to do things in multiple ways, though that is very grey territory due to it being a very dynamic, patchable language.
Just a quick note for folks interesting in joining 18F: it may be a much more fun place to work as engineer in the government, but it's still the government.
You start off with 2 weeks of paid leave accrued per year, and it'll be at least 15 years (last time I checked) of employment before you're up to 4 weeks per year. This pales in comparison to contracting shops in the DMV (DC, Maryland, Virginia) area, where the smallest I've seen is 4 weeks for brand-new employees. Over the years I've seen more and more switch to unlimited PTO.
More likely than not, you will inevitably have to deal with a "govvie" who prides one's self on doing nothing all day and getting paid more than you for it, simply because of seniority. This might sound like hyperbole, but after 6 years as a DoD contractor and getting fed up with all the bureacracy, I left for the fully private sector and I haven't looked back since in 2 years. YMMV.
at least 15 years (last time I checked) of employment before you're up to 4 weeks per year.
Except you can't get there, because you can't work at 18F for more than four years. Or at least that was what I was told when I looked into it last year.
(I have nothing against 18F, by the way -- if it's something you're interested in you should definitely look into working there, and some awesome people I know are currently there)
It's just easier to do fast proto-typing with various Tailwind classes, and then refactor common sets of HTML tags with tailwind classes, they become reusable React (or Svelte) components.