|
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 11 2015 11:24 Manit0u wrote:
@hooktits:
First of all, making your admin password more encrypted than regular users won't help that much. Just using password_hash($password, PASSWORD_BCRYPT) should be sufficient in most cases (you can expand it to password_hash($password, PASSWORD_BCRYPT, [ 'cost' => 10 ]) if you think it'll help you much). You generally want all users using the same thing since admin will be saved along them. Where they differ is their permissions.
Website security isn't all about how secure your admin account is. It doesn't mean crap if you have the most secure hashing algorithm and some crazy 128-character length password if someone can go around it by tampering with other parts of your application (giving regular users admin access, breaking into your server and seeing the code etc.). There are pretty crazy things you can do with even pretty basic XSS attacks.
Second of all, unless you absolutely have to write this thing from scratch I'd suggest you don't reinvent the wheel and go with some reliable framework instead. This will give you access to more tools right off the bat and save you a lot of time. Frameworks such as Symfony or Laravel make developing PHP apps pretty enjoyable and you get all the basic security you want with them right off the bat (SQLI, CSRF, admin/user/anonymous user authentication etc. all built-in). On top of that they're built with modern approaches and best practices in mind.
The worst thing you could possibly do here is trying to do it yourself without much experience. You'll end up with a page that's in the 90's or early 2000's security-wise (SQL statements in the views and other bullshit like that). Also, don't ever use WordPress...
Also, try to tackle one thing at a time. Right now it seems like you have a very vague idea on how your project is going to work/look like. One day spent planning can save you a week of work. Focus on that first.
Thanks for for the reply manitou
so i'm gunna touch on your second para started"website security" i totally agree and i and i am skilled in protecting again XSS attacts so that being said i kinda left that out but no worries my bad but i'm aware there is lots more to website security but i didn't wanna list every single thing that can lead to a long debate differeing opinions etc but i was asking if the whole login idea was ok because i don't wanna create a separate login. but again thats hard for your guys to say yes when you know how talented i am at securring a site (good news before the site goes live have a good friend who is a "whitehat" guy and is gunna help me test my site before its released.
in reply to what your said about about building the site from scratch your write i agree and i'm not completely doing that, i'm taking some scripts that have been proven to very secure and made some modifactions but its not ALL from scratch i just said i can code from scratch that sounded stupid when i can use some one elses scripts that have been prooven to be very secure, i'm not some word press y nub, but i agree with you.
in reply to your next statement i am very quite up to date on modern security, probably not as good as you by miles but i'm not as newb as i say i play it up a little the new thing because i know there are so many masters on here.
and as for your final reply i hope i covered everything i want to above i gotta start coding its getting late and i wanna start working on something today to make some progress,(i'm working on a pm msg system tonight) you are right i have a vauge idea and i wish i could have taken alot of time to plan the entire thing out but after i get done working on it and know what i 'm going to require i spend down time planing things but your correct i should have planned it out very well before hand. and again thanks for your reply. advice and kinds words always much appreciated 
|
Well then, back to your original inquiry. Having your regular front-facing pages have special rules for admin user (like allowing you to modify stuff) is a bad idea. If there's even a remote chance that someone can trick your app into showing the admin content to regular users you're screwed. That's why most modern websites have completely separate sections for admin stuff (preferably even without links to it anywhere in the site so those routes don't get mapped by crawlers).
|
On December 11 2015 11:55 Ropid wrote:Show nested quote +On December 11 2015 05:32 WarSame wrote:
You're right, I was just curious about it. Why is an ArrayList superior to a LinkedList, though? [...] This feels like some dirty secret that's not mentioned when learning about data structures. Here's a video of a presentation about linked lists vs. arrays from the guy that created C++: + Show Spoiler +
That's great. Thank you!
|
On December 11 2015 05:32 WarSame wrote:Show nested quote +On December 11 2015 01:10 RoomOfMush wrote:On December 11 2015 00:54 WarSame wrote:Random curiosity question - if you have two Java Linked Lists is there a more efficient way to append them together, abusing the fact that they are both Linked Lists? For example, pointing the last element in the 0th list to the 0th element in the 1st list? Note: This is not what .addAll() does. There is not. But you shouldnt be using LinkedLists anyways. There is very little reason to use them over ArrayLists or ArrayDeques. And even if there is, you wouldnt be needing micro optimizations like this. You're right, I was just curious about it. Why is an ArrayList superior to a LinkedList, though? Also, I'd like a bit of help optimizing some code. I'm trying to find the number of unique ways to make change for an int(i.e. 5 nickels and a penny is the same as a penny and 5 nickels, and only count for one way). My method of doing this is a recursive search. I want to use a HashSet for a memo table, but I'm making 4 new CoinCollection(has a number of pennies, nickels, dimes and quarters) each time, with the first taking the input CoinCollection and adding 1 penny, the second adding a nickel, the third a dime, the fourth a quarter. 4 new objects is a lot for a recursive function. However, I don't see how I can check if my current solution is in the HashSet without making these objects. It would save a lot of computation and stack space if I could avoid making them. Does anyone know how to get around making them? Is there something besides a HashSet I can use? The source code is here. coinCollections is a global variable to avoid having to put it on the stack every call, but if you have a better way of dealing with that please let me know.
Sounds like a job forrrrrr ... dynamic programming!
http://pastebin.com/YPc66gbB
Interview with Google on Wednesday, welp. This was good practice.
edit: mmmm unique ways
http://pastebin.com/7tzkReMA
ahh much faster
|
167 Posts
On December 12 2015 15:03 Blisse wrote:Show nested quote +On December 11 2015 05:32 WarSame wrote:On December 11 2015 01:10 RoomOfMush wrote:On December 11 2015 00:54 WarSame wrote:Random curiosity question - if you have two Java Linked Lists is there a more efficient way to append them together, abusing the fact that they are both Linked Lists? For example, pointing the last element in the 0th list to the 0th element in the 1st list? Note: This is not what .addAll() does. There is not. But you shouldnt be using LinkedLists anyways. There is very little reason to use them over ArrayLists or ArrayDeques. And even if there is, you wouldnt be needing micro optimizations like this. You're right, I was just curious about it. Why is an ArrayList superior to a LinkedList, though? Also, I'd like a bit of help optimizing some code. I'm trying to find the number of unique ways to make change for an int(i.e. 5 nickels and a penny is the same as a penny and 5 nickels, and only count for one way). My method of doing this is a recursive search. I want to use a HashSet for a memo table, but I'm making 4 new CoinCollection(has a number of pennies, nickels, dimes and quarters) each time, with the first taking the input CoinCollection and adding 1 penny, the second adding a nickel, the third a dime, the fourth a quarter. 4 new objects is a lot for a recursive function. However, I don't see how I can check if my current solution is in the HashSet without making these objects. It would save a lot of computation and stack space if I could avoid making them. Does anyone know how to get around making them? Is there something besides a HashSet I can use? The source code is here. coinCollections is a global variable to avoid having to put it on the stack every call, but if you have a better way of dealing with that please let me know. Sounds like a job forrrrrr ... dynamic programming! http://pastebin.com/YPc66gbBInterview with Google on Wednesday, welp. This was good practice. edit: mmmm unique ways http://pastebin.com/7tzkReMAahh much faster
Of course, if the question is just the number of ways, it can be much faster: http://ideone.com/pbxKST.
|
Guess I failed that interview
|
On December 12 2015 15:03 Blisse wrote:Show nested quote +On December 11 2015 05:32 WarSame wrote:On December 11 2015 01:10 RoomOfMush wrote:On December 11 2015 00:54 WarSame wrote:Random curiosity question - if you have two Java Linked Lists is there a more efficient way to append them together, abusing the fact that they are both Linked Lists? For example, pointing the last element in the 0th list to the 0th element in the 1st list? Note: This is not what .addAll() does. There is not. But you shouldnt be using LinkedLists anyways. There is very little reason to use them over ArrayLists or ArrayDeques. And even if there is, you wouldnt be needing micro optimizations like this. You're right, I was just curious about it. Why is an ArrayList superior to a LinkedList, though? Also, I'd like a bit of help optimizing some code. I'm trying to find the number of unique ways to make change for an int(i.e. 5 nickels and a penny is the same as a penny and 5 nickels, and only count for one way). My method of doing this is a recursive search. I want to use a HashSet for a memo table, but I'm making 4 new CoinCollection(has a number of pennies, nickels, dimes and quarters) each time, with the first taking the input CoinCollection and adding 1 penny, the second adding a nickel, the third a dime, the fourth a quarter. 4 new objects is a lot for a recursive function. However, I don't see how I can check if my current solution is in the HashSet without making these objects. It would save a lot of computation and stack space if I could avoid making them. Does anyone know how to get around making them? Is there something besides a HashSet I can use? The source code is here. coinCollections is a global variable to avoid having to put it on the stack every call, but if you have a better way of dealing with that please let me know. Sounds like a job forrrrrr ... dynamic programming! http://pastebin.com/YPc66gbBInterview with Google on Wednesday, welp. This was good practice. edit: mmmm unique ways http://pastebin.com/7tzkReMAahh much faster
Good luck.
http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html
if you haven't already seen it
|
167 Posts
On December 13 2015 02:04 Blisse wrote:
Guess I failed that interview
I don't work at Google and I promise I won't tell anyone. =]
In all seriousness, a good interviewer would nudge you in that direction. There's a big difference between asking for the number of unique ways that change can be made, and asking for all unique ways change can be made.
The question was the number of ways, but the presented recursive solution does output each way.
I'm assuming the real question was indeed the number of ways, as that number would get quite large, quite fast, and there would be too many solutions to generate and output for very small inputs.
You correctly recognized it as a dynamic programming problem, so that's halfway there. It's not a very difficult DP problem either -- it's often used as introduction to dynamic programming. I'm sure you'd have figured it out. =]
|
Everything you "have to know" according to this guy is some low level stuff. What's the point of being able to recite quicksort or implementing a balanced binary tree or what have you? You use an existing implementation whenever you can. In the rare case where you can't, you look it up (in google's case it'd be very surprised if there wasn't a reusable implementation of all these algorithms in the repository already). 5 seconds to pull up the algorithm on wikipedia, a couple of minutes to translate it into your programming language. No bugs because you didn't remember that one step of the algorithm correctly.
It's important to know which algorithms to look up or which general topic to search for the algorithm that could solve your problem. Learning algorithms by heart, however, is a waste of time at best and a source of bugs in the normal case.
But if that's what you need to get hired... not much you can do about it.
|
On December 13 2015 03:50 spinesheath wrote:Everything you "have to know" according to this guy is some low level stuff. What's the point of being able to recite quicksort or implementing a balanced binary tree or what have you? You use an existing implementation whenever you can. In the rare case where you can't, you look it up (in google's case it'd be very surprised if there wasn't a reusable implementation of all these algorithms in the repository already). 5 seconds to pull up the algorithm on wikipedia, a couple of minutes to translate it into your programming language. No bugs because you didn't remember that one step of the algorithm correctly. It's important to know which algorithms to look up or which general topic to search for the algorithm that could solve your problem. Learning algorithms by heart, however, is a waste of time at best and a source of bugs in the normal case. But if that's what you need to get hired... not much you can do about it.
Everything you say is true, but you miss the intend on these interviews. They are not trying to find out if you know your stuff, they try to find the better of 2 people who both know their stuff. If you get enough applicants for the job why not filter a little bit more thoroughly? Wouldnt hurt to separate the wheat from the chaff.
|
On December 13 2015 03:50 spinesheath wrote:Everything you "have to know" according to this guy is some low level stuff. What's the point of being able to recite quicksort or implementing a balanced binary tree or what have you? You use an existing implementation whenever you can. In the rare case where you can't, you look it up (in google's case it'd be very surprised if there wasn't a reusable implementation of all these algorithms in the repository already). 5 seconds to pull up the algorithm on wikipedia, a couple of minutes to translate it into your programming language. No bugs because you didn't remember that one step of the algorithm correctly. It's important to know which algorithms to look up or which general topic to search for the algorithm that could solve your problem. Learning algorithms by heart, however, is a waste of time at best and a source of bugs in the normal case. But if that's what you need to get hired... not much you can do about it.
I don't think he ever intended to suggest that those were exactly the topics you need to know to get hired - my interpretation was 'these are good things to study, they probably won't prepare you perfectly but it's better than going in cold.'
Steve Yegge wrote:
I considered giving out a set of tips in which I actually use variable names like X, rather than real subjects, but decided that in the resultant vacuum, everyone would get upset. Otherwise that approach seemed pretty good, as long as I published under a pseudonym.
|
On December 13 2015 03:50 spinesheath wrote:Everything you "have to know" according to this guy is some low level stuff. What's the point of being able to recite quicksort or implementing a balanced binary tree or what have you? You use an existing implementation whenever you can. In the rare case where you can't, you look it up (in google's case it'd be very surprised if there wasn't a reusable implementation of all these algorithms in the repository already). 5 seconds to pull up the algorithm on wikipedia, a couple of minutes to translate it into your programming language. No bugs because you didn't remember that one step of the algorithm correctly. It's important to know which algorithms to look up or which general topic to search for the algorithm that could solve your problem. Learning algorithms by heart, however, is a waste of time at best and a source of bugs in the normal case. But if that's what you need to get hired... not much you can do about it.
In a google interview, you are not going to be asked to recite quicksort, or implement a balanced binary tree. The point here is that if you don't already know these basic concepts very well, you're going to have a hell of a hard time answering the actual interview questions. You're not going to be questioned on rote memorization of algorithms or data structures, but you need to be very comfortable with main algorithms & data structures so that you can tackle more interesting questions.
|
On December 13 2015 04:51 RoomOfMush wrote:Show nested quote +On December 13 2015 03:50 spinesheath wrote:Everything you "have to know" according to this guy is some low level stuff. What's the point of being able to recite quicksort or implementing a balanced binary tree or what have you? You use an existing implementation whenever you can. In the rare case where you can't, you look it up (in google's case it'd be very surprised if there wasn't a reusable implementation of all these algorithms in the repository already). 5 seconds to pull up the algorithm on wikipedia, a couple of minutes to translate it into your programming language. No bugs because you didn't remember that one step of the algorithm correctly. It's important to know which algorithms to look up or which general topic to search for the algorithm that could solve your problem. Learning algorithms by heart, however, is a waste of time at best and a source of bugs in the normal case. But if that's what you need to get hired... not much you can do about it. Everything you say is true, but you miss the intend on these interviews. They are not trying to find out if you know your stuff, they try to find the better of 2 people who both know their stuff. If you get enough applicants for the job why not filter a little bit more thoroughly? Wouldnt hurt to separate the wheat from the chaff.
It hurts if throw away the wheat and keep the chaff. Someone who knows a bunch of algorithms in detail is less useful than someone who can apply a bunch of algorithms to solve problems on a more abstract level.
On December 13 2015 05:42 phar wrote:Show nested quote +On December 13 2015 03:50 spinesheath wrote:Everything you "have to know" according to this guy is some low level stuff. What's the point of being able to recite quicksort or implementing a balanced binary tree or what have you? You use an existing implementation whenever you can. In the rare case where you can't, you look it up (in google's case it'd be very surprised if there wasn't a reusable implementation of all these algorithms in the repository already). 5 seconds to pull up the algorithm on wikipedia, a couple of minutes to translate it into your programming language. No bugs because you didn't remember that one step of the algorithm correctly. It's important to know which algorithms to look up or which general topic to search for the algorithm that could solve your problem. Learning algorithms by heart, however, is a waste of time at best and a source of bugs in the normal case. But if that's what you need to get hired... not much you can do about it. In a google interview, you are not going to be asked to recite quicksort, or implement a balanced binary tree. The point here is that if you don't already know these basic concepts very well, you're going to have a hell of a hard time answering the actual interview questions. You're not going to be questioned on rote memorization of algorithms or data structures, but you need to be very comfortable with main algorithms & data structures so that you can tackle more interesting questions.
You need to know what they do and how to use them. That doesn't come across very well in the article. In fact, it's quite the opposite:
Hashtables: hashtables are arguably the single most important data structure known to mankind. You absolutely have to know how they work. Again, it's like one chapter in one data structures book, so just go read about them. You should be able to implement one using only arrays in your favorite language, in about the space of one interview.
He even specifically mentions a very low level detail in "using only arrays". If you need to implement a hashtable, you're likely doing something horribly wrong.
Now, if you're a decent programmer you likely won't have much trouble implementing a basic hash table anyways, but I really don't think that this should be something of relevance in an interview.
|
Yes, you should be able to implement a hash table. That doesn't mean you will be asked that in an interview. The questions you will be asked in an interview are typically going to be building on more basic skills.
Just being able to build a hash table out of arrays is not a useful signal for hiring committee.
I'm sorry if Steve's post was not super clear on that point. Also bear in mind it was written like 7 years ago, so some things have changed. Finally, Steve... rambles a bit. For example (another good read, but long and rambly):
https://plus.google.com/ RipRowan/posts/eVeouesvaVX
|
Wait, why would you build a hashtable out of arrays? I thought hashtables used linked lists or array lists to deal with collision.
|
You can implement a hashtable as an array of linked lists. Like a key hashes to an index in the array while linked lists are used for collisions to the same index.
|
Right, I understood that much. However, I never realized legit hashtables are implemented with arrays - what if you have 10 000 elements allocated and only use 5?
|
What do you mean by 1000 elements allocated and only use 5?
You can build a hash table instead solely with one array - search for hash table with open addressing instead of chaining.
edit: oh you mean about the size of the array. smart hash tables with open addressing resize themselves when they're full like vectors/dynamic arrays do.
|
Right, I get that too. But say you wanted to be able to store 10000 different hash values in the table - do you have to allocate all of them when you first make the table?
|
Well... yeah? If you have 10K objects to store in the hash table with open addressing then your hash table needs to be able index 10K objects at once with its array. If you pre-allocate the table to size 10K before inserting the elements then it'd be more efficient than letting the table resize itself during the insertions?
Still I have no clue what you mean by allocations. Allocations of what exactly? The object you're storing in the hash table? The hash tables backing array? It sounds like you mean the range of your hash function? You don't need to do that. You only allocate more room/resize when you start getting collisions.
|
|
|
|
|
|
EPT
