Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Comment Its not as nice as it sounds (Score 2) 151

I had that benefit at my previous company. And yeah, you can take as much time as you want. And yeah, if you cross some invisible line in the sand they can fire you. And no, that is not why I am no longer there, although that would be amusing.

What this came down to was accounting. You see, when employees accumulate time off, that counts as DEBT on the accounting books because it has to be paid out even if an employee leaves. By doing this, the company effectively wipes that slate clean. Now, they will likely make a payout to all employees for this time, so it is not like they are cheating them in any way (at least that is what happened at my previous company).

The real kicker here is that in the future, that accounting DEBT will no longer accrue, thus making the books look better on their quarterly SEC reports.

Comment Nope. (Score 1) 38

Nobody will want it unless it is a deal for them. Their old model was to essentially give money away, so yeah, it was wildly popular until they didn't have any more money to give away. If it is not advantageous to the customer, then there is no reason to use it over just buying a ticket when you show up.

Comment Re:Lying with bad math (Score 1) 229

Nahh. I hate the idea of a UBI, but am OK with the format of the Fiartax Prebate:

THE FAIRTAX PREBATE
The Prebate is designed to ensure that no American pays federal taxes on spending up to the poverty level. All valid Social Security cardholders who are legal U.S. residents receive a monthly Prebate payment equivalent to the FAIRtax paid on essential goods and services, as measured by the Dept.

UBI doesn't math. A prebate can. If the govt threw a little technology at the problem and devised a system to examine prebate in realtime per individual, then it could (in theory) be applied at the point of sale. A monthly refund is more technologically achievable, tho, and it keeps all the beancounters at the IRS employed.

Comment I did this, but with a twist (Score 1) 168

I went to turn in my resignation at my previous employer, and the department head actually suggested this to me instead. Said to give it 6 months and basically be online, and "on call" at my old job while working the new job. I explained the needs of the new job in terms of time (a lot of work that I knew I was walking into), and he was OK with me not taking on any big responsibility at the old place. While we didn't make it public knowledge, I was able to help without taking any critical roles on projects, and giving my poor bank account a much needed boost as well.

That old job was terrible, but the people there were good.

Comment Re:I would venture... (Score 1) 297

I completely agree! SPs themselves need unit/smoke tests to validate they perform as expected, and the app needs integration tests to insure the SPs are where they are expected to be.

The pain that most organizations feel from using Sql is mostly self-inflicted and caused by prioritizing the wrong design principals. The old addage, "Good, fast, cheap. Choose 2, you can't have all 3." comes to mind. Although most organizations I've dealt with in the past only paid attention to the "cheap" bit ... and sometimes not even that.

Comment I would venture... (Score 4, Interesting) 297

That the author has simply not taken the time to properly grasp the complexity of what it does, and of what it is capable. Most people who write things like this think of data in terms of traditional models ... CRUD - Create, Read, Update, Delete. A properly trained Sql expert thinks of data in terms of sets, and can perform wondrous feats on sets of data in amazingly short timeframes.

Now, just like any other programming language, it is incredibly easy to make something that works, but does so very poorly. This, too, isn't a valid reason to say that the tool itself is bad, but rather that the tool user needs more experience.

Granted, there are some parts of Sql that feel like they are from the 70s ... probably because they are. The language itself could use with some modernizing, sure, but the basic structures of the query language are insanely powerful as they are.

The author posits that "The need for an application layer with hand-written coordination between database and client renders useless most of the best features of relational databases". I would imagine he is referring to things like Entity Framework. My best advice here is to not use these things, but rather to write in terms of Stored Procedures which provide a strong API on which your application can bind. Think of the DB itself as a micro-service. If your application has (or generates) Sql embedded in it, you are in for a world of hurt in terms of long term maintainability. EF and the like are great if you are limited in terms of development time ... but there is always a price to be paid for using them. That price is "performance" 11 times out of 10.

Slashdot Top Deals

6 Curses = 1 Hexahex

Working...