require 'numbers_and_words'
def convert(locale, numbers)
I18n.with_locale locale do
numbers.map { |i| i.to_words.length }
end
end
def eliminate(locale, numbers = (1..99).to_a)
eliminated = convert(locale, numbers).uniq
if (numbers - eliminated).empty?
eliminated
else
eliminate(locale, eliminated)
end
end
%i[en es ru fr ua hu lt lv et tr de it nl se].each do |locale|
print "#{locale}: #{eliminate(locale).join ', '}\n"
end
i disagree. first you copy others, discover and then you may alter/fine tune your decision. de facto standards are standards because "we" decide them to be.
i think the article misses the main point. the articles 'bashing' PHP does not say noone ever wrote good code in PHP or ever will. rather that we should change the situation where PHP is the de facto std for beginners on the web, because in their opinion there are superior alternatives. that's a valid concern imho, i mean it is 'not valid' to question wether there is good PHP code, but it is 'valid' to question whether PHP should be the std beginners language). sry for my english.
i think you are missing the point: passwords should be hard to guess first and should be easy to remember second. the former is the stronger need.
let's say there are 500.000 english words you are choosing from and you use 4 words. that gives you 500000^4 possibilities. let's assume the words averages about 5 characters, so we will compare this to a 20(=4 words * 5 characters) character long password made of 26 types of character (english alphabet, not using numbers and other special characters), that gives you 26^20 possibilities. and 26^20 - 500000^4 ~= 2x10^28, or put it this way: (26^20) / (500 000^4) = 318 850.382..
i know a random sequence of 20 characters are very hard to remember, but 500.000 is an overestimation too. let's say we use special symbols too (50 characters) and the word dictionary has 100.000 words. (50^12) / (100 000^4) = 2.44 so we can say it is better to have a 12 character long password (made of alphanums + symbols) than 4 random word concatenated (i think 12 is somewhat a 'standard' for 'sensitive' passwords). and i would argue that on the long term multiple concatenated passwords are very hard to remember. i'm not saying this is a terrible approach, just not the silver bullet to the 'password problem' (which xkcd never claimed of course, and for 'non sensitive', 'reused'/'throwaway' passwords it may be a viable option).
i researched a few php frameworks (sy2, zend, cake, li3, kohana, etc.) a little while, and by far i'm most satisfied with lithium (li3, http://lithify.me/). depending on 5.3 seems to open up a wide range of possibilities and oftentimes i feel like 'this is the way to do it', whereas i felt like 'the framework is getting in my way' with sy2 for example.
maybe i'm missing something here but the biggest issue i see with this is it does not effectively prevent spamming/robots. the libraries which this is based on were not created with distinguishing humans and robots in mind. especially checking the $1 gesture recognizer (https://github.com/josscrowcroft/MotionCAPTCHA/blob/master/j...) i don't see if this could be used in real life (for captchas).
I wanted to give this a shot. I first thought making a chrome/safari/etc. extension/plugin/etc. to filter your feed on the github dashboard (it may be a viable option), but i settled on making api calls (and using public data only).
I pushed it to http://gfnf.heroku.com (source is at https://github.com/eLod/gfnf). The interface obviously lacks some detail, but still usable i think. You can create filters and set what to include based on languages, users and repositories. Without requirements those events are selected that matches any of the conditions (e.g. OR). With requiring user(s) for example only those events get selected whose actor is in the filter.
Of course backed with the right data this should be much easier.
I strongly disagree. Learn code if you are interested, but what ill advice is that you have to learn code?! Consider your advice from a designer perspective, should founders/coders learn design because "worst case scenario, your future designer partner will respect you for trying, ...". The same goes for scaling, you should stop and learn how to scale if you're a front-end developer because the reasons you gave?
i always ,,loved'' the variation that goes like: if 0.99... != 1, then there has to be an x that 0.99.... + x = 1.0 (or to say 1 - 0.99.. > 0 must hold), so you can start to find this x (as 0.01, 0.001, 0.0001, etc.) and fail of course. this is not so ,,simple'' as your examples (or the (10*0.99.. - 0.99..)/9) but lights the point where most people go wrong here (at least for me)
first of all i don't assume "learning only what i consider to be important" is good, not just because at the age people do not have the ability to tell what is really important (for themselves). but the key is: learning what you consider to be not important is just as important. it's like learning math: to have children learn and practice multiply for years is not about getting them the ability to multiply 2 numbers above ten in head, but giving them routine for broad topics in "real life" (from not being cheated at paying at a store to "higher level" logics of "thinking").
on the other hand i really think our education (and this is about our university education in my country - hungary) is too much based on "dictionary knowledge" in contrast to getting people able to solve real life problems (so teaching people how to think and be creative). but the k-12 education is much about getting you a "general education" (that is expected by the local society/culture). so the time is not the bottleneck here i think.
results:
so if i'm not mistaken 4 is four letters long on most of these languages, but you can see there are some other destinations on other languages