Forgot your password?
typodupeerror

Comment: Re:Attorneys (Score 5, Interesting) 730

by glenstar (#39168411) Attached to: YouTube Identifies Birdsong As Copyrighted Music
I did some negotiation with Rumblefish and Paul about 5 years ago when I ran a digital music company and I have to say that in the sea of bloodsucking fucktards that exist in music licensing Paul and Rumblefish were a breath of fresh air. They were the only company I dealt with that actually gave a flying fuck about their artists and were always very supportive of up-and-coming bands. Hell, their entire business model is around putting unknown artists on soundtracks, or in commercials, and henceforth are actually supporting the artists in a way that previously only the major labels would do.

All of that being said, it is obvious Rumblefish fucked up this time. Who knows exactly why, but they did. I think it is important that before crucifying them you understand that the service they provide is extremely valuable to artists not on a major label.... so at least give them that.

And before the venomous masses can call me a shill or whatever: we actually never did business together, nor did I remain contact with Paul, and so I have no reason to defend them other than what I stated above. People and companies fuck up some times. I have a feeling Rumblefish will learn from this mistake.

Comment: Re:BitCoin (Score 0) 528

by glenstar (#39155273) Attached to: North Korea's High-Tech Counterfeit $100 Bills
You are clever! Some people would just use their fingers to count (or straws if you aren't just drinking beer), but you, my fine sir, have found a way to count while buttraping the person on the other side of the bar! Brilliant! I can only imagine that you are the most popular patron at every establishment you frequent.

Comment: Re:This rant just proves that how important (Score 1) 354

by glenstar (#37697162) Attached to: Google Employee Accidentally Shares Rant About Google+
It really depends on what you are trying to do with Facebook. The newish Graph API is an absolute DREAM compared to the cobbled together mess that was the old API. Nearly everything you could ever care to pull from/post to Facebook is available via a fairly well thought out RESTful-ish interface. The only thing you need to pass into them is an access token which you can get with another simple call to the Graph API. The Graph API also has a push notification service so you can subscribe to events and Facebook will ping you when there are changes. I cannot believe I just posted something defending Facebook, but their API is FAR from the worst API out there.

Comment: Re:Same here (Score 1) 235

by glenstar (#37425798) Attached to: Startup Flees To Seattle Amid Amazon's Tax Fight
Washington state is downright hostile to small business. The DOR is evil and will treat you like a mega corporation even if you only have a single employee. I have had several corporations and LLCs registered in Washington (and stupidly just set up a new one here) but next time I will pay for an empty office space in Las Vegas and do it that way.

Comment: Re:Texas vs. TSA (Score 1) 570

by glenstar (#36120656) Attached to: Baby's First TSA Patdown
I had the same thing happen with my son when he was maybe 3. I began screaming at the agents and came VERY close to being arrested. I actually crossed back through the screener and grabbed my son since he had thrown himself on the floor and threw a fit. You don't fuck with a parent when their child is in distress. :-)

Comment: Re:My experience (Score 1) 758

by glenstar (#35626350) Attached to: Expensify CEO On 'Why We Won't Hire<nobr> <wbr></nobr>.NET Developers'
Agreed that the guy is an idiot but only because he publicly admitted what he did. All people in hiring positions have preferences. I used to have a thing against CompSci grads... all based on a unfortunate stream of incompetents that came to me. I got over it, but it took a few years and a couple of rockstars that were CompSci grads.

What I look for is breadth and depth of knowledge. If a candidate has the vast majority of their experience with a singular platform that may set off red flags for me. But I also understand that people have to work for a living and just because they use a platform at work that I don't care for doesn't necessarily mean I won't hire them. The type of work they have done IS very important though. In my business someone who has written custom CRMs for large corporate clients probably doesn't have the skillset I need, whereas someone who doesn't even blink when I say that we use Scala/Lift, with some Python glue and a ton of bash scripts IS someone I would want to talk to.
Books

+ - PostgreSQL 9.0 High Performance->

Submitted by eggyknap
eggyknap (1589525) writes "Thanks in large part to the oft-hyped "NoSQL" movement, database performance has received a great deal of press in the past few years. Organizations large and small have replaced their traditional relational database applications with new technologies like key-value stores, document databases, and other systems, with great fanfare and often great success. But replacing a database system with something radically different is a difficult undertaking, and these new database systems achieve their impressive results principally because they abandon some of the guarantees traditional database systems have always provided.

For those of us who need improved performance but don't have the luxury of redesigning our systems, and even more for those of us who still need traditional transactions, data integrity, and SQL, there is an option. Greg Smith's book, "PostgreSQL 9.0 High Performance" takes the reader step-by-step through the process of building an efficient and responsive database using "the world's most advanced open source database".

Greg Smith has been a major contributor to PostgreSQL for many years, with work focusing particularly on performance. In "PostgreSQL 9.0 High Performance", Smith starts at the lowest level and works through a complete system, sharing his experience with systematic benchmarking and detailed performance improvement at each step. Despite the title, the material applies not only to PostgreSQL's still fairly new 9.0 release, but to previous releases as well. After introducing PostgreSQL, briefly discussing its history, strengths and weaknesses, and basic management, the book dives into a detailed discussion of hardware and benchmarking, and doesn't come out for 400 pages.

Databases vary, of course, but in general they depend on three main hardware factors: CPU, memory, and disks. Smith discusses each in turn, and in substantial detail, as demonstrated in a sample chapter available from the publisher, Packt Publishing. After describing the various features and important considerations of each aspect of a database server's hardware, the book introduces and demonstrates powerful and widely available tools for testing and benchmarking. This section in particular should apply easily not only to administrators of PostgreSQL databases, but users of other databases, or indeed other applications as well, where CPU, memory, or disk performance is a critical factor. Did you know, for instance, the difference between "write-through" and "write-back" caching in disk, and why it matters to a database? Or did you know that disks perform better depending on which part of the physical platter they're reading? How does memory performance compare between various common CPUs through the evolution of their different architectures?

At every step, Smith encourages small changes and strict testing, to ensure optimum results from your performance efforts. His discussion includes methods for reducing and correcting variability, and sticks to easily obtained and interpreted tools, whose output is widely understood and for which support is readily available. The underlying philosophy has correctly been described as "measure, don't guess," a welcome relief in a world where system administrators often make changes based on a hunch or institutional mythology.

Database administrators often limit their tools to little more than building new indexes and rewriting queries, so it's surprising to note that those topics don't make their appearance until chapters 9 and 10 respectively, halfway through the book. That said, they receive the same detailed attention given earlier to database hardware, and later on to monitoring tools and replication. Smith thoroughly explains each of the operations that may appear in PostgreSQL's often overwhelming query plans, describes each index type and its variations, and goes deeply into how the query planner decides on the best way to execute a query.

Other chapters cover such topics as file systems, configuration options suitable for various scenarios, partitioning, and common pitfalls, each in depth. In fact, the whole book is extremely detailed. Although the tools introduced for benchmarking, monitoring, and the like are well described and their use nicely demonstrated, this is not a book a PostgreSQL beginner would use to get started. Smith's writing style is clear and blessedly free of errors and confusion, as is easily seen by his many posts on PostgreSQL mailing lists throughout the years, but it is deeply detailed, and the uninitiated could quickly get lost.

This is also a very long book, and although not built strictly as a reference manual, it's probably best treated as one, after an initial thorough reading. It covers each topic in such detail that each must be absorbed before further reading can be beneficial. Figures and other non-textual interruptions are, unfortunately, almost nowhere to be found, so despite the author's clear and easy style, it can be a tiring read.

It is, however, one of the clearest, most thorough, and best presented descriptions of the full depth of PostgreSQL currently available, and doubtless has something to teach any frequent user of a PostgreSQL database. Those planning a new database will welcome the straightforward and comprehensive presentation of hardware-level details that are difficult or impossible to change after a system goes into production; administrators will benefit from its discussion of configuration options and applicable tools; and users and developers will embrace its comprehensive description of query planning and optimization. "PostgreSQL 9.0 High Performance" will be a valuable tool for all PostgreSQL users interested in getting the most from their database."

Link to Original Source

Comment: Re:What it takes (Score 1) 997

by glenstar (#34919360) Attached to: Are 10-11 Hour Programming Days Feasible?
Where possible my "deadlines" are actually milestones based on how long I think it would take ME to perform the task. I keep my skills pretty up to date and 9 times out of 10 am a contributing member of the team so I know the code pretty well. I wouldn't fire someone for missing a deadline... I would consider it if they missed it without giving a heads up or some explanation.

Comment: Re:What it takes (Score 4, Interesting) 997

by glenstar (#34871564) Attached to: Are 10-11 Hour Programming Days Feasible?
As a startup founder, director, and CTO (not all at the same time, mind you) I would frequently send developers home if they weren't being productive... even if they were only there for 4 or 5 hours. Sometimes you hit a wall and no amount of staring at that screen is going to help. Why would I want to pay you to sit there and do nothing when I could send you home and you come back tomorrow refreshed and ready to tackle the problem? I rarely let anyone work more than 10 or 11 hours because my experience taught me that the quality of what is produced is *drastically* reduced during those death marches. Again... sure a team may roll out a dozen new features over an 18 hour day but how many bugs will that produce? More importantly, how demotivated will they be the next day on 3 hours of sleep? It's a vicious cycle that I never allow my teams to enter. It's all about the bottom line and to me inching a race forward is no good unless you meet the finish line. That being said, a developer who has to be sent home after 5 or 6 hours every day is completely worthless to me. You are either on-board or you are not. I don't care how or when you work as long as you produce product that is exceptional. A rule that I had at my first CTO gig was as follows: "I don't care if I ever see you in the office. If you miss a deadline without giving me sufficient advance warning I will fire you. You were hired because you are smart and a quality coder. I shouldn't have to babysit you." Works well if you have a driven team.
Image

Geek Squad Sends Cease-and-Desist Letter To God Squad 357 Screenshot-sm

Posted by samzenpus
from the who-would-jesus-sue dept.
An anonymous reader writes "A Wisconsin priest has God on his car but Best Buy's lawyers on his back. Father Luke Strand at the Holy Family Parish in Fond Du Lac says he has received a cease-and-desist letter from the electronics retailer. From the article: 'At issue is Strand's black Volkswagen Beetle with door stickers bearing the name "God Squad" in a logo similar to that of Best Buy's Geek Squad, a group of electronics troubleshooters. Strand told the Fond du Lac Reporter that the car is a creative way to spur discussion and bring his faith to others. Best Buy Co. tells the Milwaukee Journal Sentinel that it appreciates what Strand is trying to do, but it's bad precedent to let groups violate its trademarks.'"
Image

Girl Quits On Dry Erase Board a Hoax 147 Screenshot-sm

Posted by samzenpus
from the take-this-job-and-shove-it dept.
suraj.sun writes "It's the same old story: young woman quits, uses dry erase board and series of pictures to let entire office know the boss is a sexist pig, exposes his love of playing FarmVille during work hours." Story seem too good to be true? It probably is, at least according to writer Peter Kafka. Even so, Jay Leno and Good Morning America have already reached out to "Jenny."

When someone says "I want a programming language in which I need only say what I wish done," give him a lollipop.

Working...