Search Results

Search found 7 results on 1 pages for 'dound'.

Page 1/1 | 1

YUI Calendar: how does it load the Sam's Skin CSS?

- by dound

I'm using YUI 2's calendar in YUI 3. How does it load Sam's skin CSS? I didn't manually include it (though it seems like I should so the user can download it in the one request I make to the combo loader for css). Strangely, I don't see it being downloaded nor do I see it in the JS files themselves. I must be overlooking it. This is how I'm loading the CSS and JS now: <head> ... <link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/combo?3.1.0/build/cssreset/reset.css&3.1.0/build/cssfonts/fonts.css&3.1.0/build/cssbase/base.css"/> ... </head> ...  <script type="text/javascript" src="http://yui.yahooapis.com/combo?3.1.1/build/yui/yui-min.js&3.1.1/build/oop/oop-min.js&3.1.1/build/event-custom/event-custom-base-min.js&3.1.1/build/event/event-base-min.js&3.1.1/build/json/json-parse-min.js&3.1.1/build/querystring/querystring-stringify-simple-min.js&3.1.1/build/io/io-base-min.js&3.1.1/build/dom/dom-base-min.js&3.1.1/build/dom/selector-native-min.js&3.1.1/build/dom/selector-css2-min.js&3.1.1/build/node/node-base-min.js&3.1.1/build/node/node-style-min.js&3.1.1/build/stylesheet/stylesheet-min.js&2in3.1/2.8.0/build/yui2-calendar/yui2-calendar-min.js&2in3.1/2.8.0/build/yui2-yahoo/yui2-yahoo-min.js&2in3.1/2.8.0/build/yui2-dom/yui2-dom-min.js&2in3.1/2.8.0/build/yui2-event/yui2-event-min.js"></script> <script type="text/javascript">//<![CDATA[ YUI().use('yui2-calendar', function(Y) { var YAHOO = Y.YUI2; var cal = new YAHOO.widget.Calendar("cal",{navigator:true,mindate:'1/1/2000'); cal.render(); // ... Edit: I want to make a few minor changes to the default sam skin. What is the best way to do that? I answered this part of my question. If I wrap the calendar in an extra div, then specifying CSS rules which include that div as part of the selector makes the rule more specific so the browser uses it over Sam's skin. Rough example: <style type="text/css"> .magic .yui-skin-sam .yui-calendar td.calcell { height: 10em; width: 15em; } </style> ... <div class="magic"> <div class="yui-skin-sam"> <div id="cal"></div> </div> </div>

Read the article
YUI: ensuring DOM elements and scripts are ready

- by dound

If I put my inline script after the DOM elements it interacts with, should I still use YUI 3's domready event? I haven't noticed any problems, and it seems like I can count on the browser loading the page sequentially. (I already use YUI().use('node', ... to make sure the YUI functions I need have been loaded since the YUI script is a separate file.) Is there a way to speed up the loading of widgets like YUI 2's calendar? I load the appropriate script in <head> element of my page. I use YUI().use('yui2-calendar', ... to make sure the Calendar widget is available. Unfortunately, this causes a short but noticeable delay when I load my page with the calendar. If I omit the YUI().use('yui2-calendar', ... code then it shows up without a noticeable delay - but I guess this could cause the Calendar to not show up at all if the YUI script doesn't load in time? With regards to #2, is it possible to reduce the visual artifact of the calendar not being present and then showing up? I've made it slightly better by specifying a height and width for the parent div so that at least the space is already allocated = minimal shifting around when it does load.

Read the article
High-concurrency counters without sharding

- by dound

This question concerns two implementations of counters which are intended to scale without sharding (with a tradeoff that they might under-count in some situations): http://appengine-cookbook.appspot.com/recipe/high-concurrency-counters-without-sharding/ (the code in the comments) http://blog.notdot.net/2010/04/High-concurrency-counters-without-sharding My questions: With respect to #1: Running memcache.decr() in a deferred, transactional task seems like overkill. If memcache.decr() is done outside the transaction, I think the worst-case is the transaction fails and we miss counting whatever we decremented. Am I overlooking some other problem that could occur by doing this? What are the significiant tradeoffs between the two implementations? Here are the tradeoffs I see: #2 does not require datastore transactions. To get the counter's value, #2 requires a datastore fetch while with #1 typically only needs to do a memcache.get() and memcache.add(). When incrementing a counter, both call memcache.incr(). Periodically, #2 adds a task to the task queue while #1 transactionally performs a datastore get and put. #1 also always performs memcache.add() (to test whether it is time to persist the counter to the datastore). Conclusions (without actually running any performance tests): #1 should typically be faster at retrieving a counter (#1 memcache vs #2 datastore). Though #1 has to perform an extra memcache.add() too. However, #2 should be faster when updating counters (#1 datastore get+put vs #2 enqueue a task). On the other hand, with #1 you have to be a bit more careful with the update interval since the task queue quota is almost 100x smaller than either the datastore or memcahce APIs.

Read the article
YUI Calendar: Skinning and CSS

- by dound

I'm using YUI 2's calendar in YUI 3. I want to make a few minor changes to the default sam skin. What is the best way to do that? Also, how does it load Sam's skin CSS? I didn't manually include it (though it seems like I should so the user can download it in the one request I make to the combo loader for css?). This is how I'm loading the CSS and JS now: <head> ... <link rel="stylesheet" type="text/css" href="http://yui.yahooapis.com/combo?3.1.0/build/cssreset/reset.css&3.1.0/build/cssfonts/fonts.css&3.1.0/build/cssbase/base.css"/> ... </head> ...  <script type="text/javascript" src="http://yui.yahooapis.com/combo?3.1.1/build/yui/yui-min.js&3.1.1/build/oop/oop-min.js&3.1.1/build/event-custom/event-custom-base-min.js&3.1.1/build/event/event-base-min.js&3.1.1/build/json/json-parse-min.js&3.1.1/build/querystring/querystring-stringify-simple-min.js&3.1.1/build/io/io-base-min.js&3.1.1/build/dom/dom-base-min.js&3.1.1/build/dom/selector-native-min.js&3.1.1/build/dom/selector-css2-min.js&3.1.1/build/node/node-base-min.js&3.1.1/build/node/node-style-min.js&3.1.1/build/stylesheet/stylesheet-min.js&2in3.1/2.8.0/build/yui2-calendar/yui2-calendar-min.js&2in3.1/2.8.0/build/yui2-yahoo/yui2-yahoo-min.js&2in3.1/2.8.0/build/yui2-dom/yui2-dom-min.js&2in3.1/2.8.0/build/yui2-event/yui2-event-min.js"></script> <script type="text/javascript">//<![CDATA[ YUI().use('yui2-calendar', function(Y) { var YAHOO = Y.YUI2; var cal = new YAHOO.widget.Calendar("cal",{navigator:true,mindate:'1/1/2000'); cal.render(); // ... The main problem I'm having is that it seems to dynamically load the Sam's skin, so any CSS I specify in my stylesheet or in the <head> section seem to be overridden. I can modify the style by getting the nodes and using YUI's Node.setStyle() method, but this doesn't seem like the best way to do things. Note: The script does include more than I need for just YUI 2's calendar, but that's because I use YUI 3 for other things irrelevant to this question.

Read the article
Session ID Rotation - does it enhance security?

- by dound

(I think) I understand why session IDs should be rotated when the user logs in - this is one important step to prevent session fixation. However, is there any advantage to randomly/periodically rotating session IDs? This seems to only provide a false sense of security in my opinion. Assuming session IDs are not vulnerable to brute-force guessing and you only transmit the session ID in a cookie (not as part of URLs), then an attacker will have to access your cookie (most likely by snooping on your traffic) to get your session ID. Thus if the attacker gets one session ID, they'll probably be able to sniff the rotated session ID too - and thus randomly rotating has not enhanced security.

Read the article
Sort a list of tuples without case sensitivity

- by dound

How can I efficiently and easily sort a list of tuples without being sensitive to case? For example this: [('a', 'c'), ('A', 'b'), ('a', 'a'), ('a', 5)] Should look like this once sorted: [('a', 5), ('a', 'a'), ('A', 'b'), ('a', 'c')] The regular lexicographic sort will put 'A' before 'a' and yield this: [('A', 'b'), ('a', 5), ('a', 'a'), ('a', 'c')]

Read the article
Remove file from git repository (history)

- by Devenv

(solved, see bottom of the question body) Looking for this for a long time now, what I have till now is: http://dound.com/2009/04/git-forever-remove-files-or-folders-from-history/ and http://progit.org/book/ch9-7.html Pretty much the same method, but both of them leave objects in pack files... Stuck. What I tried: git filter-branch --index-filter 'git rm --cached --ignore-unmatch file_name' rm -Rf .git/refs/original rm -Rf .git/logs/ git gc Still have files in the pack, and this is how I know it: git verify-pack -v .git/objects/pack/pack-3f8c0...bb.idx | sort -k 3 -n | tail -3 And this: git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch file_name" HEAD rm -rf .git/refs/original/ && git reflog expire --all && git gc --aggressive --prune The same... Tried git clone trick, it removed some of the files (~3000 of them) but the largest files are still there... I have some large legacy files in the repository, ~200M, and I really don't want them there... And I don't want to reset the repository to 0 :( SOLUTION: This is the shortest way to get rid of the files: check .git/packed-refs - my problem was that I had there a refs/remotes/origin/master line for a remote repository, delete it, otherwise git won't remove those files (optional) git verify-pack -v .git/objects/pack/#{pack-name}.idx | sort -k 3 -n | tail -5 - to check for the largest files (optional) git rev-list --objects --all | grep a0d770a97ff0fac0be1d777b32cc67fe69eb9a98 - to check what files those are git filter-branch --index-filter 'git rm --cached --ignore-unmatch file_names' - to remove the file from all revisions rm -rf .git/refs/original/ - to remove git's backup git reflog expire --all --expire='0 days' - to expire all the loose objects (optional) git fsck --full --unreachable - to check if there are any loose objects git repack -A -d - repacking the pack git prune - to finally remove those objects

Read the article

1