I was in denial about it for a long time, like you. I came up with excuses, like you are doing, to explain it away and not have to deal with it.
If it really isn't so much of an issue, then how come so many women are up in arms about it? [0]
414 karma · joined May 10, 2012
If it really isn't so much of an issue, then how come so many women are up in arms about it? [0]
We don't. Especially in the tech community, everyone is assumed to be male by default. There was a post not two days ago by a woman programmer showing that a common complaint among men is that women "don't contribute technical articles". News flash: they do, but the commenters ignore the possibility that an anonymous blogger might be a woman and refer to the author as "he" anyway.
We simply do not live in the world you describe.
> To me you sound incredibly sexist.
Funny how sexists always say that to people who call out sexism.
> Sorry, but I don't divide up the world like you do.
Right, you'd rather completely ignore the issues facing this community.
> Are you saying that if a Woman made that list all is well?
In short, yeah. It's creepy for men to compose a list of 'females' without their consent and make it opt-out.
> Why does the gender of who made the list matter?
Because the tech community is utterly plagued with misogyny, sexual harassment at conferences, and people like you who want to ignore the whole issue in the name of not being told that they can't impose anything they want on a marginalized group.
We don't live in that world. Neither do we live in a world where people of color are afforded the same opportunities as white people even though they have all the same rights.
Software (and tech in general) is a toxic and often extremely sexist community towards women. It's easy to take your attitude of "not caring", but that doesn't solve the problem, it simply shuts off the light so that nasty people can do their bidding in the dark.
> I should do that because they are female?
Yes, if it's a freaking thing about women, then they should have the last freaking word. :)
> If people need to see that there are others like them in a community (do they though?), then this module list is exactly right.
This is exactly the sort of blind, toxic attitude that some of us are trying to help destroy. If women who are CPAN authors want to organize a community amongst themselves, then it's up to them to decide how they want to go about doing it. It is NOT up to men to do it for them without consulting or considering the consequences given the continued problems with sexual harassment in the tech community.
I hope this gets removed.
Great message to send to the women in the tech industry: come join our community and we'll single you out in a git repository like a museum exhibit. Even better, the whole thing is a perl script, so anyone can programmatically do whatever they want with your personal information! It's all for curiosity's sake!
Sorry, but a basic principle of security is to assume that you are already 'owned'.
If they had a viable reason to put resources into the iPad 1 and have it meet their performance and usability requirements, they would have.
Oh right, because APIs are not copyrightable or patentable and it's absolutely meaningless to attempt to assert ownership over such things.
The reason why you're the only one "theorizing" about what Apple will do is because most other people here recognize how patents and copyrights work and why there is a dispute between Apple and Samsung.
They didn't replace OS X with iOS, they each exist as expressions of a different type of computing, for different purposes.
Microsoft are attempting to provide one system as a single expression of both types of paradigm, and this is why the jury is out on Windows 8.
If I may, I'll employ another Anti-Pattern, Cargo Cult Programming[1]. This means that a team sees some method or 'One True Way' and starts implementing it without understanding why.
It's almost guaranteed to go wrong, and it tends to apply a lot to things that are hip, like this architecture and things like NoSQL.
In this case it would be moving some of the controller logic (the parts responsible for rendering views and dispatching events from the UI) to the browser, and using an API to communicate with the model (and the rest of the controller).
So, if I'm going to display a page of 10 tweets, in the classic server side architecture, I load the tweets, render a view template based on a context containing those tweets, and then send the HTML to the browser.
In an API-based web application architecture like this, I _always_ send the same HTML, which is cached in memory and is almost a no-op to send to the browser, then the client side scripting looks at the URL of the page and makes a call to a JSON or XML API that will result in those 10 tweets. These tweets are then rendered on the client side by the browser.
This is beneficial in a few ways:
* You can re-use the exact same API and expose it to third parties, who can then write apps with all the functionality of your webapp, and you've one less thing to test.
* Rendering a template can be a (relatively) time-consuming operation that may require some I/O. On a single-threaded platform like Node.js, where you simply want to dispatch an event (request) as fast as possible and move on, rendering a template takes a lot of time.
* If the time is going to be spent rendering that template anyway, you may as well crowdsource it and let the browser handle it. The browser is probably only processing one page load at a time, whereas your servers could be processing thousands or millions.
The cons of using this system are related to the benefits:
* The API you use is likely to suffer from Abstraction Inversion[1], or if that's intentionally avoided, a Leaky Abstraction[2]. The reason for this is that there may be some pages to be rendered that require more complex, or less abstract, queries on the data. On the server you could easily issue a JOIN query, but it may not make sense to expose such a thing directly via a RESTful interface. Therefore your application may end up firing numerous API requests and joining the results manually in order to complete a request. If you DO expose this functionality, it will probably end up looking very out of place and very specific.
* The extra time spent by the browser may not be suitable in all cases. It poses a number of accessibility and performance problems on certain devices. I may not be able to use a certain website with a screen reader because of this, or I may not be able to view it on an ancient version of Opera running on a shitty old phone over 3G. Even on a modern smartphone, the time taken from seeing a Twitter page's header and background with the loading indicator to actually seing the content was a pain in the ass.
* Depending on your application and architecture, you may be able to deliver even better performance by caching rendered templates than by offloading it to the browser. For example, I believe Reddit pretty much prerenders and caches every single page on the site, which is why most stuff loads instantly, but at peak times it takes a while to load the message inbox, or the 80th page of posts. This might be made even worse by extra API calls and client side rendering.
[1] http://en.wikipedia.org/wiki/Abstraction_inversion [2] http://en.wikipedia.org/wiki/Leaky_abstraction
It's not unmanageable, but it's certainly a lot harder than supporting iOS.
The function of the rule is to prevent people from creating an alternative app platform. For example, one based on the Flash runtime where you could download new applications from within this app, thereby bypassing the app store.
Companies do lots of things that don't immediately look like profit-gaining moves to investors.
Actually, put another way, do you think that Google is not a corporation, and instead a basket of goodwill, since they market things as 'open'?
Xcode and the entire stack behind it do not run on Windows or Linux. It would take a team of engineers months to pull it off, then another team to continuously support it. In those months, the feature set of Xcode and the compilers will have improved again and there would never be a stable version for a different platform.
Porting Xcode to Windows or Linux would probably be the worst idea Apple ever made.