Pft, tuning is for the DBA. If you don't want to give me full access to a DB, well fuck you optimize my shitty view full of joins.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited February 2012
Yeah, I've never been required to DB tune at any place I've worked. That's always been the territory of a DBA. At worst, I had to tweak a hint or two, or rebuild an index. As soon as you start talking about execution plans, and result caching, and b-tree balancing and crap, my eyes glaze over. Not my expertise.
Hell I assume the people who wrote the query analyzers know better than I do about tuning so I don't even use hints. I probably wouldn't know where to begin either.
Has absolutely no impact on my ability to understand concepts like pointers, so I guess potato-potahto.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
admanbunionize your workplaceSeattle, WARegistered Userregular
If I have to optimize a database everybody involved is fucked.
Though I guess if I slapped "DB tuning experience, 2 years" in my resume I'd expect to be called on that like in Gilbert's examples.
So help you if you asked me that and I didn't list that though, I'd probably ask you what the hell does that have to do with my qualifications and flip the table when you get belligerent.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
0
Options
admanbunionize your workplaceSeattle, WARegistered Userregular
The takeaways here are don't fudge your resume and don't ask your developers to tune databases.
The advantage to REST is that you are using standard HTTP verbs as your CRUD
This is literally the first statement about REST that I have actually understood.
Hehe, really? REST is really a super simple concept...but yeah, I've seen a lot of documentation about it over complicate the issue. REST is basically the concept that you can access resources (URI's) using verbs (PUT, GET, DELETE, et al) that correspond directly to the operation you are attempting.
So, GET /account/1, in most RESTful systems, would map to "GET Account with ID 1". It starts to get more complicated when you start supporting multiple output formats (GET /account/1.xml, GET /account/1.json), but it's still relatively simple.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
The funniest thing about REST, to me, is that it's what finally forced browsers and web servers to support the entire HTTP verb list, rather than just the subset that basic web browsing normally uses.
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
edited February 2012
I was hoping that I was understanding that correctly, and it seems like I was.
And, so, if you wanted to change the name of Account 1, you get the XML, change the value, and PUT it into /account/1.xml
The wikipedia article on REST doesn't make any of that clear. It seems to talk about it in a very abstract manner.
Monkey Ball Warrior on
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Yep, that's exactly right. If you wanted to delete account 1, you would do DELETE /account/1, if you wanted to see a list of accounts, you could do GET /account. You are pretty much right on track.
Though I guess if I slapped "DB tuning experience, 2 years" in my resume I'd expect to be called on that like in Gilbert's examples.
So help you if you asked me that and I didn't list that though, I'd probably ask you what the hell does that have to do with my qualifications and flip the table when you get belligerent.
Oh absolutely, if you have no experience, we don't ask you that. We have full access to the database to do whatever we want. We start with what's the difference between an inner join and an outer join, what's bulk, if you to iterate through records what PLSQL features would you use (cursors), if they know materialized views - pros and cons,
Most recent example was 2+ years of sql experience and ask for a simple " SELECT count(*) FROM customers where country = 'Canada'" is basically the right answer and they forgot the FROM. If you use SQL for 2 years, you know you need a FROM keyword.
edit - I may be a little jaded because I've done 20ish interviews over the last week half/two and not a lot are what they say they are.
Though I guess if I slapped "DB tuning experience, 2 years" in my resume I'd expect to be called on that like in Gilbert's examples.
So help you if you asked me that and I didn't list that though, I'd probably ask you what the hell does that have to do with my qualifications and flip the table when you get belligerent.
Oh absolutely, if you have no experience, we don't ask you that. We have full access to the database to do whatever we want. We start with what's the difference between an inner join and an outer join, what's bulk, if you to iterate through records what PLSQL features would you use (cursors), if they know materialized views - pros and cons,
Most recent example was 2+ years of sql experience and ask for a simple " SELECT count(*) FROM customers where country = 'Canada'" is basically the right answer and they forgot the FROM. If you use SQL for 2 years, you know you need a FROM keyword.
edit - I may be a little jaded because I've done 20ish interviews over the last week half/two and not a lot are what they say they are.
It's obviously frustrating to you, but I love those kind of guys...means when I go in for an interview, and actually know everything on my resume, at a pretty proficient level, I look good :P
I used to have to pretend I knew how to tune MySQL at my old job. I didn't do a terrible job of it, but mostly I read through a blog from a guy who used to be one of the top level InnoDB performance guys and just did what he said, did what tests he said to determine if I even needed to do stuff, etc. It did handle ~1000 qps without skipping a beat, though. I couldn't do any of it from memory if someone asked me to or even repeat what stuff I looked at at this point.
I just went back and read Gilbert0's post and that is the sort of stuff I did on a regular basis and knew wtf I was doing, though. Although if you asked me in an interview it's entirely likely I'd brainfart and sound like an incompetent liar.
I am boning up on ICD 10 for work, and I officially love it. While ICD-9 had specific code for bitten by rat, dog and unspecified, ICD 10 has a specific code for "Bitten by dolphin".
I just finished writing a HCPC reference tool
I'm waiting on ICD9/10 because there are so many goddamned ICD codes that the iPhone processor literally has no chance of handling them all in a reasonable speed.
We have a CPT and ICD search mechanism in one of the iPhone/iPad apps that I've created at work and it can definitely handle them if you do enough pre-processing, indices, etc. We have roughly 350,000 'friendly' descriptions for the ICDs that are all searched completely offline.
Keep in mind that the 350k is ICD9 only...I am not looking forward to ICD10.
I am boning up on ICD 10 for work, and I officially love it. While ICD-9 had specific code for bitten by rat, dog and unspecified, ICD 10 has a specific code for "Bitten by dolphin".
I just finished writing a HCPC reference tool
I'm waiting on ICD9/10 because there are so many goddamned ICD codes that the iPhone processor literally has no chance of handling them all in a reasonable speed.
We have a CPT and ICD search mechanism in one of the iPhone/iPad apps that I've created at work and it can definitely handle them if you do enough pre-processing, indices, etc. We have roughly 350,000 'friendly' descriptions for the ICDs that are all searched completely offline.
Keep in mind that the 350k is ICD9 only...I am not looking forward to ICD10.
I've indexed the one searchable field I tested on, and I was getting 3-4 second search times. Passable, most certainly, but not exactly zippy by iPhone standards.
I'm not saying you can't have the whole code database on the iphone and make it work, but certainly you get into more of a query-result UI model rather than what I have with HCPC which basically executes searches per keystroke.
For comparisons sake, what backend are you using for CoreData?
I've noticed that CoreData pounds the shit out of SQLite during searches which is weird because I would have assumed it would try to keep the database in memory when the app is actually running.
I am boning up on ICD 10 for work, and I officially love it. While ICD-9 had specific code for bitten by rat, dog and unspecified, ICD 10 has a specific code for "Bitten by dolphin".
I just finished writing a HCPC reference tool
I'm waiting on ICD9/10 because there are so many goddamned ICD codes that the iPhone processor literally has no chance of handling them all in a reasonable speed.
We have a CPT and ICD search mechanism in one of the iPhone/iPad apps that I've created at work and it can definitely handle them if you do enough pre-processing, indices, etc. We have roughly 350,000 'friendly' descriptions for the ICDs that are all searched completely offline.
Keep in mind that the 350k is ICD9 only...I am not looking forward to ICD10.
I've indexed the one searchable field I tested on, and I was getting 3-4 second search times. Passable, most certainly, but not exactly zippy by iPhone standards.
I'm not saying you can't have the whole code database on the iphone and make it work, but certainly you get into more of a query-result UI model rather than what I have with HCPC which basically executes searches per keystroke.
For comparisons sake, what backend are you using for CoreData?
I've noticed that CoreData pounds the shit out of SQLite during searches which is weird because I would have assumed it would try to keep the database in memory when the app is actually running.
I abandoned SQLite pretty quickly. We have a ton of offline data in addition to the ICDs/CPTs and my experience was that once it got over ~5MB of data it got painfully slow. We actually have a ton of JSON files packaged with the app that are grabbed and parsed when relevant, everything separated a way that makes sure no file is more than 500KB. My searches are currently < 1s.
There was a lot more initial work versus being able to just query, but it works for us.
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Sounds like you were just opening the SQLite db as a regular I/O stream, rather than memory mapping it. With large SQLite files, it helps to memory map the file and open it that way, speeds up working with large files considerably.
I am boning up on ICD 10 for work, and I officially love it. While ICD-9 had specific code for bitten by rat, dog and unspecified, ICD 10 has a specific code for "Bitten by dolphin".
I just finished writing a HCPC reference tool
I'm waiting on ICD9/10 because there are so many goddamned ICD codes that the iPhone processor literally has no chance of handling them all in a reasonable speed.
We have a CPT and ICD search mechanism in one of the iPhone/iPad apps that I've created at work and it can definitely handle them if you do enough pre-processing, indices, etc. We have roughly 350,000 'friendly' descriptions for the ICDs that are all searched completely offline.
Keep in mind that the 350k is ICD9 only...I am not looking forward to ICD10.
I've indexed the one searchable field I tested on, and I was getting 3-4 second search times. Passable, most certainly, but not exactly zippy by iPhone standards.
I'm not saying you can't have the whole code database on the iphone and make it work, but certainly you get into more of a query-result UI model rather than what I have with HCPC which basically executes searches per keystroke.
For comparisons sake, what backend are you using for CoreData?
I've noticed that CoreData pounds the shit out of SQLite during searches which is weird because I would have assumed it would try to keep the database in memory when the app is actually running.
I abandoned SQLite pretty quickly. We have a ton of offline data in addition to the ICDs/CPTs and my experience was that once it got over ~5MB of data it got painfully slow. We actually have a ton of JSON files packaged with the app that are grabbed and parsed when relevant, everything separated a way that makes sure no file is more than 500KB. My searches are currently < 1s.
There was a lot more initial work versus being able to just query, but it works for us.
See this is what I normally do
But this one time I decided to give CoreData a chance, and I was swiftly punished.
The advantage to REST is that you are using standard HTTP verbs as your CRUD
This is literally the first statement about REST that I have actually understood.
Hehe, really? REST is really a super simple concept...but yeah, I've seen a lot of documentation about it over complicate the issue.
And yet so many people fuck it up by basically doing RPC with URLs and claiming that that is REST.
It took me reading RESTful Web Service Cookbook (warning not actually a cookbook, actually a HOWTO on service design) to get RESTful design even though your description is REST in a nutshell and effectively all it is in its beautiful simplicity.
Also, this >Article< was really useful for getting my head around REST.
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
I didn't want to make it sound like I had spent a great deal of time wrestling with it. I probably did a cursory wikipedia and google search and dropped it after a few wtf's. This seems like it is pretty clear cut, but as usual, the proper design is the hard part.
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
Though I guess if I slapped "DB tuning experience, 2 years" in my resume I'd expect to be called on that like in Gilbert's examples.
So help you if you asked me that and I didn't list that though, I'd probably ask you what the hell does that have to do with my qualifications and flip the table when you get belligerent.
Oh absolutely, if you have no experience, we don't ask you that. We have full access to the database to do whatever we want. We start with what's the difference between an inner join and an outer join, what's bulk, if you to iterate through records what PLSQL features would you use (cursors), if they know materialized views - pros and cons,
Most recent example was 2+ years of sql experience and ask for a simple " SELECT count(*) FROM customers where country = 'Canada'" is basically the right answer and they forgot the FROM. If you use SQL for 2 years, you know you need a FROM keyword.
edit - I may be a little jaded because I've done 20ish interviews over the last week half/two and not a lot are what they say they are.
I would be lying if I told you from time to time I didn't forget a FROM.
Or a semicolon (non-database code), or a closing quote.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
RE REST: Isn't it really just using HTTP verbs the way they're supposed to be used? GET for retrieving data, DELETE for removing it, etc? Are there any frameworks that actually deal with PUT or DELETE? In my (limited) experience, frameworks like ASP.NET MVC and Symfony2 only recognize GET and POST.
---
Quick question about Ruby syntax. I've been reading the official documentation, but some of it is a bit confusing as it never shows a completed class entirely written. So, is something like the following correct?
def Person
attr_reader :name, :age
def initialization(name, age)
@name = name
@age = age
end
def to_s
"{#name}, {#age}"
end
end
I just finished updating my homepage in an effort to make myself marginally more attractive to employers. This involved editing a couple of html files in emacs, and about half way through it occurred to me that perhaps I should move forward a few decades in technology. Anyone want to recommend / provide a crash course in building a non-embarrassing web presence?
RE REST: Isn't it really just using HTTP verbs the way they're supposed to be used? GET for retrieving data, DELETE for removing it, etc? Are there any frameworks that actually deal with PUT or DELETE?
Yeah, put/delete just give a complete crud. A lot of frameworks support them.
Though I guess if I slapped "DB tuning experience, 2 years" in my resume I'd expect to be called on that like in Gilbert's examples.
So help you if you asked me that and I didn't list that though, I'd probably ask you what the hell does that have to do with my qualifications and flip the table when you get belligerent.
Oh absolutely, if you have no experience, we don't ask you that. We have full access to the database to do whatever we want. We start with what's the difference between an inner join and an outer join, what's bulk, if you to iterate through records what PLSQL features would you use (cursors), if they know materialized views - pros and cons,
Most recent example was 2+ years of sql experience and ask for a simple " SELECT count(*) FROM customers where country = 'Canada'" is basically the right answer and they forgot the FROM. If you use SQL for 2 years, you know you need a FROM keyword.
edit - I may be a little jaded because I've done 20ish interviews over the last week half/two and not a lot are what they say they are.
Funny story: During my current job search, I have answered the bolded question so many times that my relatively non-technical wife can give a perfect answer.
I just finished updating my homepage in an effort to make myself marginally more attractive to employers. This involved editing a couple of html files in emacs, and about half way through it occurred to me that perhaps I should move forward a few decades in technology. Anyone want to recommend / provide a crash course in building a non-embarrassing web presence?
Man my database knowledge is lacking, the only thing I know about joins is I let the database assume what I want to do, unless I need nulls then I get specific with an outer join.
Man I am going to look like a fool if I'm called on what exactly "experience with T-SQL and SQL/PSM" means. As for cursors... I'd rather get a very specific view/select statement rather than iterate through a large database one record at a time.
How often do I need to iterate through a list hundreds long anyways?
I really should brush up on shit I forgot.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Could someone point me toward a good resource on session-management in PHP/JS? I've got a straight PHP site right now, and I'm basically just relying on PHP to expire stuff in $_SESSION at a certain point in time, but it doesn't feel right at all. I keep thinking there must be a better way to invalidate a user's session, and to keep track of some of their data for said session. This isn't live yet or anything, so I've got plenty of time to do it (hopefully) the right way.
Posts
Has absolutely no impact on my ability to understand concepts like pointers, so I guess potato-potahto.
So help you if you asked me that and I didn't list that though, I'd probably ask you what the hell does that have to do with my qualifications and flip the table when you get belligerent.
This is literally the first statement about REST that I have actually understood.
Hehe, really? REST is really a super simple concept...but yeah, I've seen a lot of documentation about it over complicate the issue. REST is basically the concept that you can access resources (URI's) using verbs (PUT, GET, DELETE, et al) that correspond directly to the operation you are attempting.
So, GET /account/1, in most RESTful systems, would map to "GET Account with ID 1". It starts to get more complicated when you start supporting multiple output formats (GET /account/1.xml, GET /account/1.json), but it's still relatively simple.
And, so, if you wanted to change the name of Account 1, you get the XML, change the value, and PUT it into /account/1.xml
The wikipedia article on REST doesn't make any of that clear. It seems to talk about it in a very abstract manner.
Oh absolutely, if you have no experience, we don't ask you that. We have full access to the database to do whatever we want. We start with what's the difference between an inner join and an outer join, what's bulk, if you to iterate through records what PLSQL features would you use (cursors), if they know materialized views - pros and cons,
Most recent example was 2+ years of sql experience and ask for a simple " SELECT count(*) FROM customers where country = 'Canada'" is basically the right answer and they forgot the FROM. If you use SQL for 2 years, you know you need a FROM keyword.
edit - I may be a little jaded because I've done 20ish interviews over the last week half/two and not a lot are what they say they are.
PS - Our main billing app is 5 TB so performance is key to do 20,000 customers a day.
It's obviously frustrating to you, but I love those kind of guys...means when I go in for an interview, and actually know everything on my resume, at a pretty proficient level, I look good :P
I just went back and read Gilbert0's post and that is the sort of stuff I did on a regular basis and knew wtf I was doing, though. Although if you asked me in an interview it's entirely likely I'd brainfart and sound like an incompetent liar.
Well, it is called jQuery...eh? eh?!
But I'm working on centralized eHealth systems and do a lot of query development. And I have a databases specialization marked on my degree... welp.
I just got access to a hospital's legacy system today that we're sorting out data conversion to the centralized system. Oh god, MUMPS.
And they can't give me read-only access and still have access to the query system so I'm a super user to production.
I am worried that I'll kill their system with a malformed query tomorrow or something.
We have a CPT and ICD search mechanism in one of the iPhone/iPad apps that I've created at work and it can definitely handle them if you do enough pre-processing, indices, etc. We have roughly 350,000 'friendly' descriptions for the ICDs that are all searched completely offline.
Keep in mind that the 350k is ICD9 only...I am not looking forward to ICD10.
I've indexed the one searchable field I tested on, and I was getting 3-4 second search times. Passable, most certainly, but not exactly zippy by iPhone standards.
I'm not saying you can't have the whole code database on the iphone and make it work, but certainly you get into more of a query-result UI model rather than what I have with HCPC which basically executes searches per keystroke.
For comparisons sake, what backend are you using for CoreData?
I've noticed that CoreData pounds the shit out of SQLite during searches which is weird because I would have assumed it would try to keep the database in memory when the app is actually running.
I abandoned SQLite pretty quickly. We have a ton of offline data in addition to the ICDs/CPTs and my experience was that once it got over ~5MB of data it got painfully slow. We actually have a ton of JSON files packaged with the app that are grabbed and parsed when relevant, everything separated a way that makes sure no file is more than 500KB. My searches are currently < 1s.
There was a lot more initial work versus being able to just query, but it works for us.
See this is what I normally do
But this one time I decided to give CoreData a chance, and I was swiftly punished.
And yet so many people fuck it up by basically doing RPC with URLs and claiming that that is REST.
It took me reading RESTful Web Service Cookbook (warning not actually a cookbook, actually a HOWTO on service design) to get RESTful design even though your description is REST in a nutshell and effectively all it is in its beautiful simplicity.
Also, this >Article< was really useful for getting my head around REST.
I made a game, it has penguins in it. It's pay what you like on Gumroad.
Currently Ebaying Nothing at all but I might do in the future.
I would be lying if I told you from time to time I didn't forget a FROM.
Or a semicolon (non-database code), or a closing quote.
---
Quick question about Ruby syntax. I've been reading the official documentation, but some of it is a bit confusing as it never shows a completed class entirely written. So, is something like the following correct?
def Person attr_reader :name, :age def initialization(name, age) @name = name @age = age end def to_s "{#name}, {#age}" end endYeah, put/delete just give a complete crud. A lot of frameworks support them.
1. http://twitter.github.com/bootstrap/
2. ????
3. Done in 2 hours.
Man I am going to look like a fool if I'm called on what exactly "experience with T-SQL and SQL/PSM" means. As for cursors... I'd rather get a very specific view/select statement rather than iterate through a large database one record at a time.
How often do I need to iterate through a list hundreds long anyways?
I really should brush up on shit I forgot.
Could someone point me toward a good resource on session-management in PHP/JS? I've got a straight PHP site right now, and I'm basically just relying on PHP to expire stuff in $_SESSION at a certain point in time, but it doesn't feel right at all. I keep thinking there must be a better way to invalidate a user's session, and to keep track of some of their data for said session. This isn't live yet or anything, so I've got plenty of time to do it (hopefully) the right way.
http://davidwalsh.name/php-cookies
http://www.w3schools.com/php/php_cookies.asp