|
I'm confused. Is this username/password specific to person A and B or is it a standard one for the company? If the login (whether it's one per user or a universal one) is so important I think javascript might not be the way to go because if they're on Computer 1 and the JS is running on Computer 1, someone clever/malicious enough will probably be able to extract it. This depends on what's at stake about the site being accessed outside of the company. Is it meaningless red tape that came out of policy (ie. managing the whole "kicking other users off" thing) but nothing is really too vulnerable and training/guidance/trust would be enough, or does it really offer a black eye for the company that escalates it to Not Even Once levels of security? If it's the former where the people can be controlled to some degree, depending on their trustworthiness, you can just provide some policy ranging anywhere from communicating "hey these logins have to be used here only so just use this widget and never log in from anywhere else" all the way to "if you're ever caught trying to obtain or otherwise misuse this login you'll be fired/expelled/beheaded please sign here to acknowledge" (though if it needs to be that extreme you might as well treat it as the latter). If it's in the Not Even Once category you might want to take the login stuff out of javascript completely and come up with a way that will prevent them from ever having access to the password, ie. someone can pick apart javascript or hidden form elements and so on but won't get anywhere. There's a wide number of ways to do that, some of the better ones depend on whether you can work directly with whoever runs that site. E:F,B Bhaal fucked around with this message at 23:48 on Apr 3, 2013 |
# ? Apr 3, 2013 23:44 |
|
|
# ? May 28, 2024 13:26 |
|
This sounds like a terrible policy problem that can be solved with terrible policy rather than technology. Tell everybody that if they access the site on a computer other than Computer 1, they're fired.
|
# ? Apr 3, 2013 23:52 |
|
It's not super secure poo poo that will cause a black eye publicly, more stupid rear end policy and red tape; they want to implement a technical solution to a problem that stems from a lack of trust. It doesn't sound like the idea that I had is the way to go. Thank you everyone for your advice.
|
# ? Apr 4, 2013 01:44 |
|
americanzero4128 posted:It's not super secure poo poo that will cause a black eye publicly, more stupid rear end policy and red tape; they want to implement a technical solution to a problem that stems from a lack of trust. It doesn't sound like the idea that I had is the way to go. Thank you everyone for your advice. If they're using a service that wants them to pay per-user licensing, and they're trying to hack stuff up so everyone can use it while they only pay for one license, that could actually cause problems if it came out publicly. Just sayin'.
|
# ? Apr 4, 2013 02:07 |
|
Jabor posted:If they're using a service that wants them to pay per-user licensing, and they're trying to hack stuff up so everyone can use it while they only pay for one license, that could actually cause problems if it came out publicly. Just sayin'. You are correct. I'll bring the solution to my manager to pay for more licenses since that is what should be done. Consider it dropped. Thanks.
|
# ? Apr 4, 2013 02:23 |
|
So I got this idea to make an online text adventure kind of thing and I've gotten pretty far. The "command line" works like it's supposed to and I have a blinking cursor and all that jazz. But I'm kind of stumped on how to print out a string and have there be a delay between characters. So instead of a line magically appearing it would look like a character at a time is showing up. To make the cursor blink I used "setInterval" but I'm pretty sure that won't work for what I'm trying to do, will it?
|
# ? Apr 5, 2013 04:11 |
|
I'm trying to make a really simple chrome script that would swap an image for another image, but I can't seem to get it to work. The JavaScript works fine, but I can't get it to run from the extension in dev mode. Here is my manifest.json: code:
code:
code:
post hole digger fucked around with this message at 05:00 on Apr 5, 2013 |
# ? Apr 5, 2013 04:30 |
|
Tres Burritos posted:To make the cursor blink I used "setInterval" but I'm pretty sure that won't work for what I'm trying to do, will it? Why wouldn't it work? The easiest way to do this is to keep a copy of the string you want to display somewhere, and every 100ms or so append the next character in that string to wherever you're displaying it.
|
# ? Apr 5, 2013 04:48 |
|
Jabor posted:Why wouldn't it work? Welp poo poo, didn't see that there was a clearInterval function too. Thanks.
|
# ? Apr 5, 2013 04:54 |
|
e: already solved by a rad dude. The answer was matchList.list.sort(function(a,b) { return a.score-b.score }). Newf fucked around with this message at 06:49 on Apr 5, 2013 |
# ? Apr 5, 2013 06:25 |
|
You could do something like the following, which will sort the array.JavaScript code:
|
# ? Apr 5, 2013 06:50 |
|
Tres Burritos posted:So I got this idea to make an online text adventure kind of thing and I've gotten pretty far. The "command line" works like it's supposed to and I have a blinking cursor and all that jazz. JavaScript code:
Wheany fucked around with this message at 11:24 on Apr 5, 2013 |
# ? Apr 5, 2013 11:20 |
|
Cawd Rud posted:You could do something like the following, which will sort the array. Sorry man. It looks like you're just a little bit less rad than that other guy.
|
# ? Apr 5, 2013 15:43 |
|
I haven't worked with jQuery much, having been (unfortunately) limited to ExtJS for work, and am now using it on a personal site. I have a div that I'm loading with Ajaxed data, and I re-use the same div for multiple queries. In Chrome, everything works fine, but in Firefox I will get rapid flickers of the old content that was once in the div that settle down after a few seconds. It happens the worst when rapidly clicking to change the div's contents. I'm doing it like so: code:
|
# ? Apr 9, 2013 18:25 |
|
pksage posted:
I think you need to provide a bit more context, because I don't think that code has causes flickering on any browser. How does the above code get called? In a mouse event handler, for example, so it fires multiple times?
|
# ? Apr 9, 2013 18:32 |
|
Wheany posted:How does the above code get called? In a mouse event handler, for example, so it fires multiple times? Whoops! My bad. It's in a click() event -- more specifically, a click() event tied to a class. I have one of those annoying alphabet headers; you know, "# | A | B | C ", that kind of thing. Each letter queries the database for that letter's contents, and I have that done up as a click event on the letter class: code:
|
# ? Apr 9, 2013 18:37 |
|
Can you post a sample at http://jsfiddle.net or another site like that that shows the flickering?
|
# ? Apr 9, 2013 18:50 |
|
Suspicious Dish posted:Can you post a sample at http://jsfiddle.net or another site like that that shows the flickering? Here's the live site. (If it looks like :files:, don't worry, it's just a front-end for a Rock Band modding community.) http://www.pksage.com/ccc/snarfblat.php Click several letter headers in quick succession in Firefox to see the flicker in action. Hopefully.
|
# ? Apr 9, 2013 19:18 |
|
I don't get any flicker, but by the 6th or 7th click, it's dog slow, eating resources like crazy and the images aren't loading, so you're doing something very wrong. Are there event hooks on the elements you're replacing that you could be unhooking before replacing them?
|
# ? Apr 9, 2013 19:26 |
|
Munkeymon posted:I don't get any flicker, but by the 6th or 7th click, it's dog slow, eating resources like crazy and the images aren't loading, so you're doing something very wrong. Are there event hooks on the elements you're replacing that you could be unhooking before replacing them? This was it! I thought I was doing an .empty() on the letters every time, but I wasn't, so it was stacking the click handler on top of the existing click handler. All I had to do was add .off("click") before the handler binding. Thanks!
|
# ? Apr 9, 2013 19:33 |
|
Well I just did some load impact tests with Node.js/Express running 1 Heroku web dyno on a fairly process intensive page, and the results are pretty good. Node maintained a pretty consistent response time regardless of concurrent connections: http://loadimpact.com/test/view/1338055 It also had 0 failed responses. I don't know how it would do with something like 1,000 concurrent connections (does anyone have any idea how I could test this?), but I'm pretty glad I ended up working with Node.
|
# ? Apr 10, 2013 22:12 |
|
Knyteguy posted:I don't know how it would do with something like 1,000 concurrent connections (does anyone have any idea how I could test this?), but I'm pretty glad I ended up working with Node. You can use a performance testing service like Blitz.io (https://www.blitz.io/) or create an army of EC2 instances manually.
|
# ? Apr 10, 2013 22:37 |
|
I am trying to build an order form, and having trouble figuring out how to start with it. A sample document from my products database might look something like this:code:
I've been wrestling with this for a while, and I'm just not sure what the best course of action is. My best guess would be to take the selected option value Id when the size menu is changed and use it to filter the skus by checking if it exists in the sku valueIds. Then use the remaining skus to create the color menu options by going the other direction: make color values available only if they exist in the remaining sku valueIds, and then wrap them in option tags and append to the color select. And continue the process on any additional options ad infinitum until only one sku remains to be displayed. If that is a decent solution, my next problem is writing some not-lovely code for it. Does anyone have any suggestions on where to start with this? Hopefully that all made sense.
|
# ? Apr 17, 2013 01:27 |
|
Not a question, but a remark. I tried to convert my backbone app from "I kind of guessed as I went" architecture to something more alike tbranyen's backbone-boilerplate. I was using global namespaces for "modularizing" before, stuff like window.MYAPP.helpers.doStuff() and that was working ok, except the JS purists still think that's terrible and want you to go full AMD. So I spent a couple of days figuring out how backbone-boilerplate was doing it, and that was definitely challenging, having never used a build process in a website and having never tried requirejs. Boilerplate uses a mix of bower, jam.js all connected together by require.js. The cherry on top is this beefy grunt script that does everything from jshint to single file concatenation and uglifying, including also 2-3 different UT frameworks. I ended up starting with converting the project to just require.js for now without any of the additional magic, which took forever, but hopefully is worth it in the long term. One of those "sometimes you gotta go slow to go fast" things. Anybody has experience with require.js / amd and build pipelines that they'd like to share?
|
# ? Apr 17, 2013 02:32 |
|
DreadCthulhu posted:
Did you get RequireJS to compile your project into a single file yet? You don't need anything besides code:
code:
Here is app.build.js: code:
|
# ? Apr 17, 2013 04:09 |
|
Ah thanks, that sounds pretty straightforward. I'm going to have to figure out the correct pathing for that config file first since my stuff is all over the place in the different vendor/non-vendor folders.
|
# ? Apr 17, 2013 07:58 |
|
DreadCthulhu posted:Ah thanks, that sounds pretty straightforward. I'm going to have to figure out the correct pathing for that config file first since my stuff is all over the place in the different vendor/non-vendor folders. I'll make a repo on GitHub and post it up here if I can't find a good example for you. My r.js projects right now are private so I can't post the links.
|
# ? Apr 17, 2013 08:26 |
|
Roosevelt posted:If that is a decent solution, my next problem is writing some not-lovely code for it. Does anyone have any suggestions on where to start with this? Hopefully that all made sense. It sounds ok to me. I have a question, though: Is there a reason valueIds has a string value, and not e.g. "valueIds": {"Size": 1, "Color":3} (or "valueIds": [1,3], if you want to go with unlabeled values for some reason)?
|
# ? Apr 17, 2013 08:33 |
|
This may come off as a rhetorical question, but is there any good reason to write in Javascript instead of Coffeescript when working on large projects? Large as in a size measured in kLOCs. Coffeescript isn't perfect, but it's just vastly superior to Java in terms of its ability to write and maintain. If the added difficulty debugging(which is hopefully going to get reduced by source maps) or the need to maintain an existing codebase in Javascript isn't an issue, is there any good reason? Or if not Coffeescript, some other more modern, less lovely language than Javascript?
|
# ? Apr 17, 2013 09:47 |
|
The Insect Court posted:This may come off as a rhetorical question, but is there any good reason to write in Javascript instead of Coffeescript when working on large projects? Large as in a size measured in kLOCs. Coffeescript isn't perfect, but it's just vastly superior to Java in terms of its ability to write and maintain. If the added difficulty debugging(which is hopefully going to get reduced by source maps) or the need to maintain an existing codebase in Javascript isn't an issue, is there any good reason? Or if not Coffeescript, some other more modern, less lovely language than Javascript? Javascript is better known than Coffeescript. That's about it, since you dismissed the really big reason (debugging).
|
# ? Apr 17, 2013 10:01 |
|
The Insect Court posted:This may come off as a rhetorical question, but is there any good reason to write in Javascript instead of Coffeescript when working on large projects? Large as in a size measured in kLOCs. Coffeescript isn't perfect, but it's just vastly superior to Java in terms of its ability to write and maintain. If the added difficulty debugging(which is hopefully going to get reduced by source maps) or the need to maintain an existing codebase in Javascript isn't an issue, is there any good reason? Or if not Coffeescript, some other more modern, less lovely language than Javascript? I find that static analysis, such as with JSHint, is a nice reason to prefer JavaScript over CoffeeScript. It's much easier for my editor to tell that I made a syntax error and flag it right when I hit enter to start a new line. That's also why I use semi-colons in JavaScript - if I forget to finish a line then my editor will flag the line immediately using JSHint integration.
|
# ? Apr 17, 2013 10:19 |
|
I think the question really is "What advantages does using Coffeescript actually give you?". They're probably smaller than you think. Just skimming the Coffeescript page, the big selling points it mentions are mainly various syntactic sugars, which are the sort of things that help make code in small projects a bit clearer, but don't really address the real problems you encounter when building large projects.
|
# ? Apr 17, 2013 14:04 |
|
Stoph posted:I find that static analysis, such as with JSHint, is a nice reason to prefer JavaScript over CoffeeScript. It's much easier for my editor to tell that I made a syntax error and flag it right when I hit enter to start a new line. That's also why I use semi-colons in JavaScript - if I forget to finish a line then my editor will flag the line immediately using JSHint integration. That's just a case of the tools catching up though really. I use Coffeescript for my personal projects, and in my opinion it beats Javascript hands down for reading and writing. Javascript has a shed load of bracing and it turns into a soup at times, even when you manage it well, where as Coffeescript gives you the syntax in whitespace to make that structure easier to follow. Syntax checkers don't always catch dropped braces, which is very difficult to catch by eye as well; entirely white-space dependant structure is much easier to read and debug in my opinion. With my setup (Vim using Syntastic) I get a syntax check every file save, which has been enough for me -- Coffeescript is simple enough that I don't tend to make many typos, and it simplifies all the verbose stuff in Javascript so you end up with very little to get wrong. For what it's worth I've never bothered with Source Maps either, the Javascript output is really not that much different from the Coffeescript, so I've never had problems following it and relating back to the source. Jabor posted:I think the question really is "What advantages does using Coffeescript actually give you?". They're probably smaller than you think. Yeah, I can agree with this. It doesn't provide anything you need to make managing large Javascript projects necessarily easier, you still have to figure how you want to modularise your code and structure it at a high level perspective. That said though, readability is huge in large projects because you're much more likely to hit code that you don't remember and need to relearn, which is where easy to read structure comes in handy. I don't think it's enough of a difference to be worth translating all your code in a large project, unless you have some really poorly styled Javascript on your hands, but in greenfields I reckon there's definitely benefits. Maluco Marinero fucked around with this message at 14:12 on Apr 17, 2013 |
# ? Apr 17, 2013 14:08 |
|
Roosevelt posted:I am trying to build an order form, and having trouble figuring out how to start with it. A sample document from my products database might look something like this: The "not lovely code" part is fairly easy, but your data structure is.... less than optimal, to put it nicely. The first thing I would do given your structure is to write something that parses into something that fits your needs better. So we want a Size collection, and then inside each size, we have a collection of shirts. I'm going to make some assumptions based on this: code:
Assumption the first: That valueIds always contains a sizeId, colorId pair. Assumption the second: That the id for size and color are both known and unchanging (at least in the short term). So sizeId of '2' is ALWAYS 'Large', and a colorId of '4' is ALWAYS 'blue' If those assumptions are correct, we can write some code, but I don't want to be barking up the wrong tree.
|
# ? Apr 17, 2013 14:35 |
|
Maluco Marinero posted:That's just a case of the tools catching up though really. I use Coffeescript for my personal projects, and in my opinion it beats Javascript hands down for reading and writing. Javascript has a shed load of bracing and it turns into a soup at times, even when you manage it well, where as Coffeescript gives you the syntax in whitespace to make that structure easier to follow. Syntax checkers don't always catch dropped braces, which is very difficult to catch by eye as well; entirely white-space dependant structure is much easier to read and debug in my opinion. My main and singular problem with coffeescript lately has been -> vs => honestly. I had a case lately that didn't get caught until it went out where the code was something like: code:
I do mean to try out WebStorm and source maps soon and see how that works, right now I'm coding with Sublime Text 2.
|
# ? Apr 17, 2013 15:29 |
|
Lumpy posted:Assumption the first: That valueIds always contains a sizeId, colorId pair. Right. Even if this tshirt product were more complex and had a third option that was unavailable to some skus, there would still be a valueId with the name "N/A". Lumpy posted:Assumption the second: That the id for size and color are both known and unchanging (at least in the short term). So sizeId of '2' is ALWAYS 'Large', and a colorId of '4' is ALWAYS 'blue' Yes, the option values all have unique id's, and they aren't changing in the near future. Lumpy posted:The first thing I would do given your structure is to write something that parses into something that fits your needs better. So we want a Size collection, and then inside each size, we have a collection of shirts. I'm interested to see where you're going with this. Part of the trouble I'm having is that the product base isn't only "t-shirts." There are dozens of different types of product, and they don't all necessarily use "size" and "color." The db schema I have is really generic, so that clicking on any given product will just load options 1, 2, 3, etc., and not specifically options size, color, and style. Hard for me to think that abstractly and I'd love some new insight.
|
# ? Apr 17, 2013 16:48 |
|
The Insect Court posted:This may come off as a rhetorical question, but is there any good reason to write in Javascript instead of Coffeescript when working on large projects? JavaScript really isn't that bad most of the time, and everything I'd really want (some builtin form of string formatting, better Unicode handling) isn't something CoffeeScript would or can fix. "use strict" fixes most of the really bad issues. The lack of automatically binding method closures can be a bad thing, and the braindead naming decisions behind "prototype" weren't exactly the smartest idea, but it's not insurmountable. CoffeeScript has some tools to help you manage those, but you first have to understand them to figure out why you use => instead of -> here, etc.
|
# ? Apr 17, 2013 23:38 |
|
Jabor posted:I think the question really is "What advantages does using Coffeescript actually give you?". They're probably smaller than you think. Obviously, since Coffeescript is ultimately just Javascript, it can't really change the semantics. But given how much of a pain in the rear end a lot of Javascript syntax is to work with, syntactic sugar is a big positive. There are plenty of examples of Coffeescript one-liners involving syntactical sugar like list comprehensions that would require vastly more code in plain Javascript. The lack of a module system is a glaring oversight when it comes to programming with Javascript in the large, but that's not something Coffeescript can fix by itself, and the available solutions like requirejs are still compatible with Coffeescript. On a related subject, what's the best choice of library to eliminate callback spaghetti code? Or should I just use IcedCoffeescript?
|
# ? Apr 18, 2013 01:13 |
|
I thought CoffeeScript was dumb, then I actually worked on a project that uses it and discovered that it cuts the line count in half while making code significantly more readable. I can't really imagine ever choosing to use pure JS over it for a non-toy project.
|
# ? Apr 18, 2013 03:57 |
|
|
# ? May 28, 2024 13:26 |
|
The Insect Court posted:On a related subject, what's the best choice of library to eliminate callback spaghetti code? Or should I just use IcedCoffeescript? Promises/Deferreds On a related note, I really recommend everybody look at the new ES6 that might be coming out within the next 7 years if we're lucky. It's got some sweet specs, and it's literally just Python with braces at this point. Destructuring assignment kicks list comprehension's rear end. yield statements will be in ES6, so you can make a trampoline. See: http://taskjs.org/ But right now promises / deferreds will turn your pyramid of callbacks into a simple jQuery chain of callbacks: JavaScript code:
JavaScript code:
|
# ? Apr 18, 2013 04:23 |