I share in your pain. This world is openly cruel to men that don't follow gender norms, and we often have to wear uncomfortable masks to keep ourselves safe from all the jerks out there. It is exhausting to wear those masks all day, and sometimes we just can't take it anymore and have to withdraw from everyone.
But there are also lots of people out there that know better than to mistreat someone for their gender expression. There are people out there that even find it worth celebrating. If you there is a community of nonbinary/gender nonconforming/genderqueer organizers near you, that can be a good place to start looking. And maybe someday, with enough help from your community and possibly therapy, you can learn to celebrate yourself for how you express yourself too. You are worthy of it.
> If you there is a community of nonbinary/gender nonconforming/genderqueer organizers near you, that can be a good place to start looking.
I think this is completely the wrong advice for who you're talking to. From the sounds of it he's complely, unquestionably a man who wants to present as completely, unquestionably a man too, but doesn't for whatever reasons.
It seems like you're saying "yeah you're a girly man, that's what you are now, better learn to embrace it" rather than "learn to express yourself how you want".
> It seems like you're saying "yeah you're a girly man, that's what you are now, better learn to embrace it" rather than "learn to express yourself how you want".
It's true, I am saying that. I think the root problem is how the parent comment author is being treated, rather than how he is acting, since his main motivation for changing how he acts is to be treated differently.
He's free to reject my advice, but I know that when I was a younger person going through the same thing, it was exactly this advice that helped me survive after many years of only being ineffectively told that I needed to "man up."
Same, to some extent. It helped that I have a lot of queer friends and did when I was a teenager too. Some things I don't like about my expression but can't (easily) change, I've learnt to accept. Qualities which I once thought of as feminine, such as emotional expressiveness, I now see as gender-neutral and they fit a lot more comfortably into my masculinity... but I have also cultivated a lot of traits that are seen as traditionally masculine as I've grown into my 20s.
I did "man up", just in a very positive way aided by having a lot of female and queer friends, rather than the regressive 4chan way I was told to when I was a teenager. Your comment read not as encouraging that, but as, "you might as well accept your fate now and start wearing a dress."
I think it depends a lot on where you live. I live in a bigger city and, while I don't personally act in an overtly out of the ordinary way, there are tons of people here from all walks of life acting in all sorts of ways who are generally accepted by society. Of course there will always be the occasional asshole, but it certainly doesn't stop most from being the person they want to be.
No, it's corporate income tax, a direct tax imposed by the federal government on corporations. The rate can be 15% to 35% but there are so many deductions available that large companies like Amazon are often able to dodge it completely. For instance, the article mentions a $917 million deduction on stock options exercised by employees, which was probably the bulk of the deductions.
That 20% drop brought its stock value back to where it was a year ago, which was an all-time high for it then. Investors that have held it for longer than a year can still sell it at a profit.
But no one is talking about investors holding stocks for more than a year in this comment chain. That's tangential to this comment chain, sorry.
And to your point, investors could have sold for over 25% of profit as well if they had sold it earlier today. So I still stand by saying that this is huge change. Besides, this thread is not about long term, just invest in index funds so I just fail to see the point.
I was coming from the perspective that there is really no such thing as a short term investor, because when you sell, you are dependent on what people think the long term prospects of the stock are.
Your desire for a "hipster small town, built around bikes and walkability" describes the cores of a lot of college towns: Olympia, Missoula, Boise, Eugene, Arcata, Davis, Bozeman, etc. They all have good coffee, too! Not sure if there are similar towns in Canada.
However, a common lament in these towns is that housing costs are increasing as people move there from the cities. It can be... socially awkward... to be a carpetbagger in a place where everyone knows everyone else's story. Maybe that's why you've mentioned taxes and basic income in your comment.
100% agree! I would also add Ann Arbor, Michigan to the mix. These "small towns" have wonderfully integrated colleges into the small town such that there are positive benefits for both including good schools and things to do...what many "freelancers" with kids want.
The problem with that glib-sounding notion is that, besides being, potentially, a chicken-and-egg issue, is that the amount of available, suitable land is much more limited than the vastness of, for example, the USA, would suggest.
The first could be solved by something like the UK's New Towns, although that requires a level of government involvement that is likely politically impossible in the US and perhaps Canada, as well.
The second is the more important issue, since, based on many of the comments, people don't seem to merely want to live nearby to another few thousand people. They also want lakes, forests, mountains, or some other geographic or natural feature. They also need provisions and Internet, which means pre-existing infrastructure nearby.
A lot of this advice (pay down high-interest debt first, have an emergency fund) is reasonable no matter what the market conditions are.
But the common wisdom is that "time in the market beats market timing." Since these boom-and-bust cycles tend to happen over 7-10 year periods, and you really can't predict when they'll happen exactly, I think a market-related investment can be rational at any point in the cycle, as long as it's considered untouchable for ten years.
Yes. If you dollar-cost-average into funds (e.g. invest the same dollar amount every month), you will automatically buy more shares when the market is low and fewer when the market is high. Long term this is exactly what you want to do, and it doesn't depend on being able to predict price movement.
I even buy gasoline this way, because prices at the pump seem to change almost randomly. I buy $25.00 at a time. So I buy more when the price is low and less when the price is high.
> I even buy gasoline this way, because prices at the pump seem to change almost randomly. I buy $25.00 at a time. So I buy more when the price is low and less when the price is high.
At the risk of a joke flying right over my head, I'll ask how this works. Isn't your gas usage mostly inelastic? Are you going to drive to work less or to the supermarket less because your tank is almost empty due to gas prices being higher? If you're thinking about planning a road trip, do you say "nah, only got half a tank of gas" due to your $25 not buying you as much? Wouldn't it be easier to just look at the price of gas and decide based on that?
It works if $25 of gas lasts long enough to get to a different price (harder at a bad price), and your tank has sufficient room to hold $25 of gas (harder at a good price). Those constraints make it worse than real dollar cost averaging, but it should still work.
You can do better if you can predict gas prices but that's sort of the point of DCA - it's a strategy that works without insight.
Edit: this strategy has a higher sample rate when gas prices are bad. This causes a problem if prices are temporally correlated, which they are, unless the sample distance is large enough that the price has enough time to become completely randomized, which is a big ask.
My strategy has always been to just plan on refilling around a half tank, and at that point I just fill up the next time I'm near one of the gas stations that I know to have cheap gas. Gives me a little cushion if it's a holiday weekend or something (which always have higher prices) and I avoid driving way out of my way just to save $0.10 per gallon for gas. If it's real insane, you put $10 in the tank to hold you over until prices drop or you can get somewhere cheaper.
Thought that was how most people did it, but I guess my gasoline-investment strategies may not be as savvy as I thought. Gotta pump up those numbers! /s
(it's a bad idea anyway to drive on less than half a tank - during the summer you can overheat your fuel pump, and during the winter you will tend to pick up water in the tank)
Long term you don't really have a choice about not buying gas, it just is what it is. It's funny how people obsess over it, or will go way out of their way for cheaper gas, when most of the time you're talking about a full tank costing you an extra buck or two, and you burn maybe a tank a week. The greedy strategies (fill up when you need it, with a slight preference to cheaper gas when you can get it) are going to produce pretty optimal results so why obsess about it?
As a city person, I have to disagree about the lack of alternatives. Walking to the grocery store, or if it's really far, cycling to the grocery store, will do wonders for the gas bill.
Yes, that may mean relocating to a part of town where the next grocery store is not 10 miles away.
Some of these functions (like SIGN, STUFF, and PARSENAME) set off little alarms in my head that sound vaguely like a full-stack developer furiously yelling "DON'T HANDLE THIS IN YOUR DATABASE LAYER."
Of course we don't always have that option, but I feel like I have to acknowledge those alarms if I'm going to use them.
I implore you to reconsider. I used to hold this opinion very strongly, have since changed my mind, and began to question why I ever held it in the first place. Now I realize it was rather simple: the first few teams I worked on had a database administrator that wasn't one of the engineers. We would avoid doing anything in the database because the iteration cycle would take months, involve many emails, and we'd end up with something different than what we wanted. In other words, it was a social problem, not a technical one.
If you empower engineers to change the database, these problems go away. At MixRank, we deploy a handful of schema migrations every day— they're a normal part of our development flow. In particular, we embrace constraints (who doesn't like avoiding invalid data?), and triggers extensively. Once we started using triggers, we noticed all sorts of awkward and inefficient patterns in our code that were contortions to avoid adding a single function into the database.
I'm currently really feeling the limitations of MySQL's auto-increment and of InnoDB's inability to deal with constraints that include multiple tables for a complex data source I am trying to efficiently represent in a local schema. Having a trigger which calls a function seems so much more powerful (if admittedly more boilerplate for the simple case).
I've always shied away from UDF, but that's more from not wanting another language to deal with and since there's fairly poor support for them in MySQL (which I'm stuck with). For example, the default mysqldump options for all databases don't include UDF unless you specifically request them with--routines. :/
STUFF is actually needed in the database layer to not kill performance of your app. SQL server has no built in convenience function the equivalent of mysql's GROUP_CONCAT. Instead, you do a subquery in the selected field, interpret it as XML, pull out the specific XML elements you are looking for as a list, and then use STUFF to join them.
As much as you might recoil in horror at this (and I still do), it's actually fairly performant because the optimizer recognizes the subquery is dependent on the main query, and does the equivalent of a join under the covers or something.
E.g.
# MSSQL
SELECT
movie.id,
movie.name,
STUFF( (SELECT ','+producer.last_name FROM actor WHERE producer.movie_id = movie.id FOR XML PATH(''), TYPE).value('.', 'NVARCHAR(32)'),
FROM movie;
# MySQL
SELECT
movie.id,
movie.name,
GROUP_CONCAT(producer.last_name),
FROM movie
LEFT JOIN producer ON movie.id = producer.movie_id
In the latest version of the SQL standard (SQL:2016) the LISTAGG function was added for this purpose. I find it "disturbing" that the next SQL Server release gets a function for this, but the new function doesn't follow the new standard.
Even worse: the name "string_agg" was apperently borrowed from PostgreSQL. But if you think that SQL Server will stick to the syntax of PostgreSQL's string_agg — nope. They use the same function name, but a different syntax.
That doesn't exactly surprise me. MSSQL feels like MySQL's old MyISAM table type technology that's been hacked and extended for decades rather than a shift to something more technologically competent. I still get errors on a regular basis about the deadlock manager killing queries because they became deadlocked. Because of course the way to deal with your system easily running into deadlocks is just to implement a checker that runs once a second and kills those queries that deadlock, and not to actually make the system work better....
This is even more ludicrous when you consider all the extremely cool stuff the team responsible for porting MSSQL to other platforms accomplished in order to get it functioning on Linux[1].
> Because of course the way to deal with your system easily running into deadlocks is just to implement a checker that runs once a second and kills those queries that deadlock, and not to actually make the system work better....
If your database design and code frequently deadlocks, I'd argue it is not a sign of the database engine being incompetent. After all, it's doing what you asked it to do. The comparison to MySQL is simply not true and it ignores the years of new features and enhancements to the product.
I admit it's entirely possible most of my bad experiences with SQL Server is due to a horrible schema. I don't control the schema in this case, nor the majority of different types of queries that run against that schema.
What I do know is that I routinely get single, non-transactional select queried deadlocked and killed. That seems like something that shouldn't happen. If I had to guess, it's likely because of the subselects to approximate group_concat, as outlined above, and they have different lock times than the main query, allowing for this single query to attampt to get locks at different times. Unfortunately, this is an ORM generated query, so sticking NOLOCK all over the place is easier said than done, and since I don't control the DB, I can't change default transactional levels. Perhaps that would solve it too.
It just seems odd that what appears to be (from my admittedly non SQL server expert) eyes to be a fairly standard database schema is so easily susceptible to this problem.
I find their locking issues interesting: they are supporting snapshot isolation for quite some time now, but it's still not default and the community even hardly knows about it. Hint's like NOLOCK are more often suggested as "fix" as considering snapshot isolation.
Unfortunately, my experience with SQL Server is almost entirely in interfacing with a third party applications SQL Server back-end. As such, I have zero control over the many queries that are run from the application clients and the schema in use. I just get to play in their sandbox. Unfortunately, like many sandboxes, it's also a litter box. :/
Every time I've used STUFF that way I've had hopelessly atrocious performance. Simply dire. In the end I've found that re-implementing GROUP_CONCAT using SQLCLR is far more performant.
But ultimatley, the fact that queries are so tied to the flat resultset is infuriating, and that sucks for every SQL engine. I want a graph of results, not a goddamned glorified spreadsheet.
There are ORMs that mitigate that limitation, but ultimately they're getting compiled down to SQL so in the middle there's a big flat resultset coming back or a bunch of redundant queries.
> There are ORMs that mitigate that limitation, but ultimately they're getting compiled down to SQL so in the middle there's a big flat resultset coming back or a bunch of redundant queries.
Yes. It's important to be very aware of this. Letting the ORM do this for you automatically for a few chained joins can result in a massive resultset that is literally 90%+ redundant information depending on the strategy the ORM uses.
Which, imho, is why we need to stop making excuses for SQL. It's better than the terrible "NoSQL" alternatives for a lot of reasons, but it's still far outstayed its welcome.
We're past due for something new. Something that natively works with the typed-graph thinking of the client code instead of forcing everything into the flat resultset, but otherwise keeps the ACID guarantees and the relational model.
I think PostgreSQL makes this the clearest because it supports arrays:
SELECT
movie.id,
movie.name,
array_remove(array_agg(producer.last_name), NULL) AS last_names
FROM movie
LEFT JOIN producer ON movie.id = producer.movie_id
GROUP BY
movie.id,
movie.name;
I used STUFF all the time until I found and implementation [https://groupconcat.codeplex.com/] of MySQL's GROUP_CONCAT as a SQLCLR function (well, actually they had to create multiple variants to allow sorting and custom delimiters).
It's certainly more ergonomic than STUFF, and I've found its performance to be comparable or better.
YMMV but one method I like to mitigate the issue the article talks about is keeping documentation in source control, and requiring a change to documentation (or explanation why there should be no documentation change) in association with the resolution of a JIRA ticket.
Maybe it's just practicality: there's not much business sense in having leaders that publicly work against some of the most deeply meaningful interests of a significant portion of their employees.
In 1976 George HW Bush declared that the CIA wouldn't manipulate the media anymore but this NYT article from a couple months later shows the feds backpedaling on that promise, along with some specific examples of media manipulation from the time:
http://www.nytimes.com/1976/04/27/archives/cia-will-keep-mor...
I haven't found any evidence of post-Cold War media manipulation of this sort, but I don't think American trust in the media has ever fully recovered since those days.
It's likely that the state agencies have learned to better avoid the exposure of these sorts of programs.
Regardless, The Intercept has more than a few stories[0], and Chomsky has shared his opinion[1]. Then there's the small matter of this[2]. And on and on; much of it is hard to verify, like Eglin Air Force base and its Reddit links.
Spreading propaganda is not the same as cooperation with the TLAs. If you read Chomsky in detail, he is describing exactly how this works, and it does not involve spies telling the NYT what to write. It's a lot more gentle.
Seriously, if you're so keen to criticize the western media you might as well do it right. Chomsky wrote several books (E.g. Understanding Power) documenting and detailing how it works.
Now, back to where we started. Where is your evidence specifically for "The New York Times has a long history of cooperating with three-letter agencies"?
I'm a solo developer in a non-tech group and I'm all about this. I add every idea to the issue tracking system. I prioritize based on consensus, feasibility, and alignment with our group's strategy. Half the ideas won't ever materialize and that's okay, because the other half are more important.
But there are also lots of people out there that know better than to mistreat someone for their gender expression. There are people out there that even find it worth celebrating. If you there is a community of nonbinary/gender nonconforming/genderqueer organizers near you, that can be a good place to start looking. And maybe someday, with enough help from your community and possibly therapy, you can learn to celebrate yourself for how you express yourself too. You are worthy of it.