|
No, but that's why I've signed up for all your news letters and don't use any adblockers. (My brain is usually more efficient for adblocking in any case.)
But there's a down side to that, you have to develop your site for IE aswell. 
Wrong is evil and must be defeated. - Jeff Ello
(√-sh*t) 2
|
|
|
|
|
Something else to keep in mind; it's not that adblock itself is inherently a huge consumer of memory: It's that the mix of global and site specific filters defeats the browsers caching mechanism that would otherwise only have a single copy of the css exist in total; combined with the fact that if you populate your filter list via subscription, instead of a small list suitable for the sites you browse you end up with an enormous list of filters to block the entire internet a few dozen to a few hundred rules to block ads on sites you visit will have an order of magnitude or two less impact than a few thousand rules to also block the 99.9% of the net you never visit.
I don't have any memory usage stats; but I regularly speed up slow slideshow sites by adblocking the crap out of the rest of the page...
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I find this a "chilling" story: [^].
"Little has been discussed in public about U.S. Cyber Command’s specific capabilities since, though budget documents detail a growing commitment to this form of warfare. The Pentagon’s cyberwarfare budget has grown from $3.9 billion in 2013 to $4.7 billion in 2014 and an estimated $5.1 billion in 2015."
"The first commander of U.S. Cyber Command, then-Army Gen. Keith Alexander, gave Congress in 2013 one of its first public overviews of how quickly an offensive cyberwarfare mindset was spreading across the Pentagon. In military parlance, it means “normalizing” cyberoperations into the daily routine.
“We have no alternative but to do so because every world event, crisis and trend now has a cyber-aspect to it, and decisions we make in cyberspace will routinely affect our physical or conventional activities and capabilities as well,” Gen. Alexander told lawmakers."
«OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. » Alan Kay's clarification on what he meant by the term "Object" in "Object-Oriented Programming."
|
|
|
|
|
When the Pentagon levels the playing field, they really level the playing field. 
|
|
|
|
|
|
And y'all think it's a good idea to connect your fridge.
|
|
|
|
|
|
|
Would be kind of fun to have a trained attack fridge that didn't involve me getting pelted with frozen veggies.
|
|
|
|
|
Makes me think of that scene in Maximum Overdrive where the Coke machine was firing cans of coke at the baseball players.
|
|
|
|
|
BillWoodruff wrote: “We have no alternative but to do so because every world event, crisis and trend now has a cyber-aspect to it, and decisions we make in cyberspace will routinely affect our physical or conventional activities and capabilities as well,”
The worlds of William Gibson appears to more and more real every day.
Marc
|
|
|
|
|
Instead of having boots on the ground, we're now having "bytes on the ground" !!
I'd rather be phishing!
|
|
|
|
|
For a field with such a reputation for solitary, antisocial tendencies, we sure are starting to rely on one another. "Me and you And you and me"
|
|
|
|
|
I tried pair programming many, may years ago. Didn't take long before we were at each other's throats - it is something I will never do again and having seen it happen the same way with other people, I would never recommend it. It only seems to work where you have a dominant/submissive pair.
|
|
|
|
|
I have only found this to be effective in particular circumstances - bug finding and fixing, usually of something old or convoluted.
This is because four eyes are better than one.
It doesn't work for green field development because all necessary design decisions should have been made before coding and thus it just becomes an exercise in minor coding-style conflict resolution which impairs the ability to think clearly.
Of course - segregated pair development (where one person writes the (TDD?) unit tests for the other's code and vice versa) is a different matter.
|
|
|
|
|
Almost like 2 people trying to drive the same car, sooner or later it will...
|
|
|
|
|
It was called "extreme programming" 15 years ago. My experience is that it doesn't really work for new code, but it's great for debugging.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Pair programming?
Is that like when one person does all the work while the other flips around on a smart phone all day? I think that is an industry wide standard now... although it is not always done at the same desk.
Actually, I hate pair programming, it is a very irritating situation of either trying to work while being badgered the whole time, or trying to give input while being ignored the whole time.
Now mentoring... that I enjoy (from either point of view).
|
|
|
|
|
Pair programming and mentoring work really well when there is a specific and obtainable goal, whether it's helping to debug some code, walk through an implementation to teach how something is done, or simply code review.
If you don't state the goal of the PP session up-front, then it's usually a waste of time, as one person ends up watching the other (the dominant/submissive pattern mentioned above.)
Often enough, I end up doing pair programming remotely, which I've found works quite well, and possibly even better than side-by-side PP. The reason being, PP works best when there's a "breathing" motion to it -- for example, when debugging, we may diverge in figuring out why the bug is happening and then converge on the solution. It's a lot easier to do remotely because in addition to the shared screen, we can individually explore different paths as well, whether it's looking at different code, inspecting the database, googling for alternative implementations, drawing out some architecture.
So, the key, in my opinion, to good PP is to avoid the monolithic "let's look at what this is doing together" but rather, "you look at this while I look at that" which brings more information to the problem at hand while simultaneously dialoging about one's findings. I find that to be a very effective and efficient approach.
Marc
|
|
|
|
|
Pair-programming works great, for most people, for short periods of time with focused goals.
Some teams may flourish using the paired approach full-time. I think this would be the exception to the rule.
My #1 rule, there is no silver bullet approach.
Red flags are triggered in my mind when I am in a discussion or read an article where someone makes an absolute statement about a process being the key to success in programming.
On the other hand, mentoring is not a process to create better code quality. It is a training process to train developers in the craft of programming. The quality of your mentor will determine the overall effect the mentoring has on the improvement of that developer.
Here's a key to superior code quality: Write code without mistakes
|
|
|
|
|
ORM is a terrible anti-pattern that violates all principles of object-oriented programming, tearing objects apart and turning them into dumb and passive data bags. "There are as many opinions as there are experts."
|
|
|
|
|
Kent Sharkey wrote: ORM is a terrible anti-pattern that violates all principles of object-oriented programming,
There are numerous, far better ways to solve the problem they were trying to solve with ORM.
Like Flying Cars
Just like flying cars. Oh, when will we get the flying cars?
Flying cars are a terrible idea. Why? Because people would be driving them and people are dangerous enough in 2 dimensions, let alone 3.
Your Reply, Before You Actually Reply
I already know the replies to this: oh, no, we will have computer systems that will pilot the flying cars. Yes, yes. The future is all chrome. I saw it all in the 50s movies.
Let's all just forget about two things:
1. ORMs
2. Flying cars
|
|
|
|
|
Re Flying Cars... I want a flying car, I don't want you to have a flying car. 
|
|
|
|
|
That's funny. you are exactly right about that.
PIEBALDconsult wrote: I want a flying car, I don't want you to have a flying car
|
|
|
|
|
Unfortunately there are many more opinions than experts.
Quote: the entire idea behind ORM is wrong
Yes, yes it is. But "solution providers" need to sell a "problem" in order to sell their product. No problem -- no sales.
Quote: more than 10 years already
Ergo, before generics. Generics are a much better "solution" to this particular non-problem.
I also agree with...
Luca Cavagnoli: SQL-speaking objects is a terrible anti-pattern that violates all principles of object-oriented programming
Indeed. Another particular anti-pattern I hear is "an object should be able to persist itself" -- no, an object should absolutely not
know how, where, when, or whether it is stored; that leads to tight coupling. If it can save itself to SQL Server, can it also save itself to Oracle, MySQL, or XML? Or are those options no longer achievable without a whole ton of refactoring?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
