|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On December 08 2013 18:05 ambikalx wrote:
Hey guys! It's been a while since I've hit this thread up. This is a web dev question this time! I have been learning PHP/jQuery with MySQL and I'm interested in creating an online travel agency kind of site that searched to see which tour guides were available on user selected dates. I'm looking for advice on what may be the best way to store the calendars/availability of all of the guides. My current idea is to only store reserved dates in the guide's table and reference another table which contains rules set by the guide (not available on weekends, prices are $x on these days, etc.). Can anyone see any pitfalls of doing it this way? Does anyone know of a better way I could go about doing this?
Thanks for your help!
Good database design theory is to make tables scalable and to be as specific as possible.
Databases can have constraints set on them if you want. But having an administrative table for things that can change is a good idea.
I learned a lot from here:
https://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/
I don't think it's a good idea to only use two tables for this.
And making calendars is difficult imo. There are many intricacies to dates that are hard to program and php isn't the best language to work with dates.
|
On December 07 2013 22:58 sluggaslamoo wrote:Show nested quote +On December 06 2013 22:05 bangsholt wrote:On December 06 2013 12:10 sluggaslamoo wrote:On December 06 2013 10:27 bangsholt wrote:On December 05 2013 07:45 sluggaslamoo wrote:On December 05 2013 00:30 darkness wrote:Does anyone here like Objective-C? I'm starting to hate it with a passion by now. I find Java's syntax and way much better and easier.  It has some nice features, it was great for its time but I'm sure if it wasn't for apple it would be long dead by now. Thanks for your opinion and all the great argumentation you have present on the subject of why you are starting to hate it with a passion. I'm currently playing around with a great mix of Jenkins, Stash and JIRA, in order to make it build automagically and run a few simple static code analysis and unit testing on my code. People out there who have actual experience with how well this works in a work scenario - I'm thinking it will work great, because it will enable us to put out a lot of metrics, which then can be measured and possibly drawn conclusions on, if someone feels that brave, but I would like to hear from people who have a similar setup as well. Thanks in advance for your time. What is it you want to know? Continuous Integration and Testing is one of the reasons I actually get hired haha I mean yeah I've used Jenkins a lot, JIRA I don't really like but then again I don't really like any kind of digital scrum/agile software and prefer to use real cards, I don't have experience with Stash specifically but Atlassian software seems to be very good in general from using Bamboo. It will be a long time before I move away from Github though if ever  I've read the idea with CI is that you make a new build every time you commit to the Git server on the master branch. What I don't really understand is the part where testing comes into the picture, one would assume you run all the tests prior to commit the code, and each commit should be atomic.
Or is it a case of you over time accumulate some tests that take a lot of time to run and you don't want to run each time that you compile?
It's this sort of questions I wonder a bit about - again, thanks for your time You are pretty much on the ball there, both of those statements are true. Ideally you would want to do a "full build" before pushing to your branch, but in large projects where it takes an hour to do that it is not possible. So on your local machine you may just be content with core scenario tests, integration tests and unit tests, and then CI handles the bigger picture. Then you have a "build light" that checks CI periodically, and will alarm everybody if someone broke the build and blame them for it When this happens, everyone should stop committing until the bug is fixed. Show nested quote +I've read the idea with CI is that you make a new build every time you commit to the Git server on the master branch. Got a bit confused by the "make a new build every time", do you mean run the build? If so yes, normally you have nightly builds, source control event-based and on-demand builds for each type of test, and for each branch. Your event based builds would trigger when your git repository receives an update. Normally you wouldn't want to be pushing to master, you want to be merging into it from your version branch. There should be a protocol to only merge into master after a "full build" which is basically every single test which sometimes can take hours. It may look something like this Master-Nightly-FullBuild Master-Nightly-Load-Test Version1.1-Nightly-FullBuild Version1.1-Unit-Tests Version1.1-Integration-Tests Version1.1-Scenario-Tests-Minor Version1.1-Scenario-Tests-All Version1.1-E2E-Tests Version1.1-Load-Test
Yes, I meant run the build
I got a better idea of the whys now, thanks for that to you, phar and Morfildur
|
On December 08 2013 18:29 obesechicken13 wrote:Good database design theory is to make tables scalable and to be as specific as possible. Databases can have constraints set on them if you want. But having an administrative table for things that can change is a good idea. I learned a lot from here: https://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/I don't think it's a good idea to only use two tables for this. And making calendars is difficult imo. There are many intricacies to dates that are hard to program and php isn't the best language to work with dates.
Thanks for the response! That link was just what I needed. I had been absolutely in the dark as far as how to structure my databases/tables. I read up on the entity-relationship model and have a much better idea of what I'm doing now.
Also, I totally forgot that I am actually going to be taking Database Design & Development next semester in my CS major *slaps forehead*. We will be learning about ERM, so I guess I'm going to have a bit of a head start on the class
|
On December 08 2013 20:46 bangsholt wrote:Show nested quote +On December 07 2013 22:58 sluggaslamoo wrote:On December 06 2013 22:05 bangsholt wrote:On December 06 2013 12:10 sluggaslamoo wrote:On December 06 2013 10:27 bangsholt wrote:On December 05 2013 07:45 sluggaslamoo wrote:On December 05 2013 00:30 darkness wrote:Does anyone here like Objective-C? I'm starting to hate it with a passion by now. I find Java's syntax and way much better and easier. It has some nice features, it was great for its time but I'm sure if it wasn't for apple it would be long dead by now. Thanks for your opinion and all the great argumentation you have present on the subject of why you are starting to hate it with a passion. I'm currently playing around with a great mix of Jenkins, Stash and JIRA, in order to make it build automagically and run a few simple static code analysis and unit testing on my code. People out there who have actual experience with how well this works in a work scenario - I'm thinking it will work great, because it will enable us to put out a lot of metrics, which then can be measured and possibly drawn conclusions on, if someone feels that brave, but I would like to hear from people who have a similar setup as well. Thanks in advance for your time. What is it you want to know? Continuous Integration and Testing is one of the reasons I actually get hired haha I mean yeah I've used Jenkins a lot, JIRA I don't really like but then again I don't really like any kind of digital scrum/agile software and prefer to use real cards, I don't have experience with Stash specifically but Atlassian software seems to be very good in general from using Bamboo. It will be a long time before I move away from Github though if ever I've read the idea with CI is that you make a new build every time you commit to the Git server on the master branch. What I don't really understand is the part where testing comes into the picture, one would assume you run all the tests prior to commit the code, and each commit should be atomic.
Or is it a case of you over time accumulate some tests that take a lot of time to run and you don't want to run each time that you compile?
It's this sort of questions I wonder a bit about - again, thanks for your time You are pretty much on the ball there, both of those statements are true. Ideally you would want to do a "full build" before pushing to your branch, but in large projects where it takes an hour to do that it is not possible. So on your local machine you may just be content with core scenario tests, integration tests and unit tests, and then CI handles the bigger picture. Then you have a "build light" that checks CI periodically, and will alarm everybody if someone broke the build and blame them for it When this happens, everyone should stop committing until the bug is fixed. I've read the idea with CI is that you make a new build every time you commit to the Git server on the master branch. Got a bit confused by the "make a new build every time", do you mean run the build? If so yes, normally you have nightly builds, source control event-based and on-demand builds for each type of test, and for each branch. Your event based builds would trigger when your git repository receives an update. Normally you wouldn't want to be pushing to master, you want to be merging into it from your version branch. There should be a protocol to only merge into master after a "full build" which is basically every single test which sometimes can take hours. It may look something like this Master-Nightly-FullBuild Master-Nightly-Load-Test Version1.1-Nightly-FullBuild Version1.1-Unit-Tests Version1.1-Integration-Tests Version1.1-Scenario-Tests-Minor Version1.1-Scenario-Tests-All Version1.1-E2E-Tests Version1.1-Load-Test Yes, I meant run the build I got a better idea of the whys now, thanks for that to you, phar and Morfildur
NP. And if you do get pushback from people at your work who are dragging their feet about setting up proper building and testing, you should be able to explain how much time you'll save in the long run if you invest up front.
|
Anyone have experience developing/contributing for Open Stack? My master's is to make a scheduler for it, so any info I could get on working for it and getting started with some community interaction would be appreciated
|
On December 09 2013 08:14 ambikalx wrote:Show nested quote +On December 08 2013 18:29 obesechicken13 wrote:Good database design theory is to make tables scalable and to be as specific as possible. Databases can have constraints set on them if you want. But having an administrative table for things that can change is a good idea. I learned a lot from here: https://www.simple-talk.com/sql/database-administration/ten-common-database-design-mistakes/I don't think it's a good idea to only use two tables for this. And making calendars is difficult imo. There are many intricacies to dates that are hard to program and php isn't the best language to work with dates. Thanks for the response! That link was just what I needed. I had been absolutely in the dark as far as how to structure my databases/tables. I read up on the entity-relationship model and have a much better idea of what I'm doing now. Also, I totally forgot that I am actually going to be taking Database Design & Development next semester in my CS major *slaps forehead*. We will be learning about ERM, so I guess I'm going to have a bit of a head start on the class
No problem. I took an intro to databases course this semester and I thought that link helped me a lot to understand entity relationship design.
|
I've got my first ever technical interview tomorrow, with Google for their Eng. Practicum Internship. Any advice?
|
On December 09 2013 13:38 jWavA wrote:
I've got my first ever technical interview tomorrow, with Google for their Eng. Practicum Internship. Any advice?
Talk. Specifically, when you work through problems, vocalize your thought process to the best of your ability. Interview questions are meant to expose how you think, and you won't be able to show that off without saying something.
|
Don't lie to your interviewer!
|
^ These are very good tips. Always think out loud, that way the interviewer can write effective feedback on what you're thinking. Never lie, because interviewers can tell
If you take only one thing from TL on interview tips, let it be what Kambing said above. THINK OUTLOUD. Even if you're stuck, keep describing why you're stuck, where you're drawing blanks, what you know and what you think you don't know. It's really weird to get used to at first, but it is a necessary thing for technical interviews.
On December 09 2013 13:38 jWavA wrote:
I've got my first ever technical interview tomorrow, with Google for their Eng. Practicum Internship. Any advice?
Specifically on the EP part, realize that the interviewers should know that you have less experience than a normal interview candidate. If you don't know something, that's fine, just be up front about it so you don't work yourself into a hole. I hosted a couple of EP interns this summer, and they were definitely very green about software development coming in. That's ok, and your interview should be calibrated to take that into account.
It may be a bit rough if this is really your first technical interview, it can take awhile to get used to.
And then one of the local Googlers up here has a... rant, we'll say, on google interview process. It's mostly geared towards fulltime SWE, not EP, but a lot of it will apply. The middle sections on algorithms, data structures, practice, Big-O, it's all pretty good. I can't remember if EP are explicitly supposed to know about complexity theory, so if there's some stuff on there that you don't recognize, it may not apply for you. Also your recruiter may have given you more detail about what you're expected to know.
http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html
Even if you don't get in, don't be discouraged, apply again next year, and apply to many places. You'd be a freshman or sophomore right now if you're applying for EP, so you have time still
good luck~
|
Say a user cannot cause a crash, but a programmer may pass some parameter that is out of boundaries. Is it good in this case to have all methods contain some boundary check (even if the programmer is the only person able to cause it) or is such check unnecessary?
Sub-question to the above one. What is preferred assuming both are available: if statement or try/catch blocks? When to go one over another?
I'm curious what to do for my individual university project. I'd like to do my best with the knowledge I have at the moment.
I use Java if it matters.
|
On December 11 2013 13:22 darkness wrote:Say a user cannot cause a crash, but a programmer may pass some parameter that is out of boundaries. Is it good in this case to have all methods contain some boundary check (even if the programmer is the only person able to cause it) or is such check unnecessary? Sub-question to the above one. What is preferred assuming both are available: if statement or try/catch blocks? When to go one over another? I'm curious what to do for my individual university project. I'd like to do my best with the knowledge I have at the moment. I use Java if it matters.
You allude to it in your problem description, but the way to think about error-handling is asking yourself the question "is this a user-facing or internal API"? Users are considered untrustworthy and if there is a way to break or otherwise exploit your system, they will do it. In contrast, you trust yourself to do the "right thing" because you have control over how you use the system.
Regardless of the answer to this question, these sorts of pre-conditions you impose on your functions (resp. programs) should be documented in some form, e.g., in a comment. They are part of the interface to those functions and must be respected for your functions to perform as expected.
Whether you introduce more safe guards other than documentation depends on your answer to the question above. In the case of internal APIs, it is fine to not include any explicit checks. Some languages such as Java allow for assertions to be expressed that fit this mold. The statement assert e; evaluates the boolean expression e and raises an error if e is false. These asserts can be toggled on (for debugging) and off (for deployment) via flags to the compiler.
For user-facing APIs, it is a matter of good style to either "engineer" out these corner cases or otherwise provide internal checking to ensure that the inputs to the functions meet the functions' pre-conditions. If-statements are appropriate for this purpose. Try-catch blocks are typically reserved for exceptional cases that might occur during the execution of a function, e.g., a network socket getting yanked while you are reading in packets. They are not appropriate for merely checking these sorts of pre-conditions.
|
|
|
On December 11 2013 13:22 darkness wrote:Say a user cannot cause a crash, but a programmer may pass some parameter that is out of boundaries. Is it good in this case to have all methods contain some boundary check (even if the programmer is the only person able to cause it) or is such check unnecessary? Sub-question to the above one. What is preferred assuming both are available: if statement or try/catch blocks? When to go one over another? I'm curious what to do for my individual university project. I'd like to do my best with the knowledge I have at the moment. I use Java if it matters.
If you need to check parameter values for which you have set up preconditions but dont check for them in the code you should use asserts. It will be easy to read from your code what boundaries you expect the function to work in without the user having the hassle with errors which might not be errors.
How much you want to do it is a cost/benefit of how many errors you will catch from yourself vs how long you use on writing them.
|
I have a question about databases. I took a dbms course last semester, and we specifically used psql. At the same time I was taking a mongodb course online as well. One thing that caught my attention was how easy it is to scale mongodb due to its flexibility, but this brings up a question: How do relational databases scale? It seems like you have to know all the details, such as the relationships between tables, before the application is built. And adding any extra features may denormalize the relationships you had before and just complicate things further (sorry, I haven't built anything big yet, so I don't have any concrete examples).
|
On December 11 2013 18:13 windzor wrote:Show nested quote +On December 11 2013 13:22 darkness wrote:Say a user cannot cause a crash, but a programmer may pass some parameter that is out of boundaries. Is it good in this case to have all methods contain some boundary check (even if the programmer is the only person able to cause it) or is such check unnecessary? Sub-question to the above one. What is preferred assuming both are available: if statement or try/catch blocks? When to go one over another? I'm curious what to do for my individual university project. I'd like to do my best with the knowledge I have at the moment. I use Java if it matters. If you need to check parameter values for which you have set up preconditions but dont check for them in the code you should use asserts. It will be easy to read from your code what boundaries you expect the function to work in without the user having the hassle with errors which might not be errors. How much you want to do it is a cost/benefit of how many errors you will catch from yourself vs how long you use on writing them.
Aren't asserts only for testing/debugging? I've searched for that on google, and I didn't find very positive suggestions to keep asserts in code for long.
|
Hyrule19167 Posts
Asserts in deployment are a pain in the ass.
|
On December 11 2013 13:22 darkness wrote:Say a user cannot cause a crash, but a programmer may pass some parameter that is out of boundaries. Is it good in this case to have all methods contain some boundary check (even if the programmer is the only person able to cause it) or is such check unnecessary? Sub-question to the above one. What is preferred assuming both are available: if statement or try/catch blocks? When to go one over another? I'm curious what to do for my individual university project. I'd like to do my best with the knowledge I have at the moment. I use Java if it matters.
For me there is one golden rule for error checking in programming:
In every userbase, no matter how big or small, there is at least one user that will manage to get the system into an invalid state. If you are the only user of the system (or method), it will eventually be you.
That means, even if you think you know that you always pass the right parameters into a function, eventually you will mix something up or forget the boundary conditions. That is why i check every parameter to every function (It's really not that much in a strongly typed language like java) because i know that eventually i will screw up. Noone remembers how the code he wrote 6 month ago really works in detail. There are some minor exceptions, for example in private methods i'm less strict about checking, though i still do check most of the input.
Then again, i'm really, really paranoid.
|
On December 12 2013 05:35 darkness wrote:Show nested quote +On December 11 2013 18:13 windzor wrote:On December 11 2013 13:22 darkness wrote:Say a user cannot cause a crash, but a programmer may pass some parameter that is out of boundaries. Is it good in this case to have all methods contain some boundary check (even if the programmer is the only person able to cause it) or is such check unnecessary? Sub-question to the above one. What is preferred assuming both are available: if statement or try/catch blocks? When to go one over another? I'm curious what to do for my individual university project. I'd like to do my best with the knowledge I have at the moment. I use Java if it matters. If you need to check parameter values for which you have set up preconditions but dont check for them in the code you should use asserts. It will be easy to read from your code what boundaries you expect the function to work in without the user having the hassle with errors which might not be errors. How much you want to do it is a cost/benefit of how many errors you will catch from yourself vs how long you use on writing them. Aren't asserts only for testing/debugging? I've searched for that on google, and I didn't find very positive suggestions to keep asserts in code for long.
Asserts are meant to capture pre-conditions/invariants in your code that are not explicitly checked. They are precisely the set of properties about your code that are "assumptions" that you assume will hold but trust the user of that code to get right. For example:
"The argument to factorial should be non-negative."
"Your helper function expects a non-null object."
"Your file processing function expects a file handled that has been opened but not yet closed."
In particular, the Java assert statement lets you express these in code versus in comments and gives you mechanism to have them checked (morally, when debugging) or not checked (morally, when deploying) as needed.
|
FYI, this week is Computer Science Education week!
http://csedweek.org/
This year, the code.org are pushing a nationwide movement for everyone to spend an hour of their time this week to learn how to code or teach a friend or family member how to code. Check out:
http://csedweek.org/learn
For tutorials for virtually all ages for a variety of technologies, with and without computers!
|
|
|
|
|
|
EPT
