Text
jQuery(document).ready(function(){ new DaWanda.Widget({ hideLogo:"false", language:"en", linkColor:"#267ED5", titleFontSize:"12", borderWidth:"10", textColor:"#5d5d5d", title:"yonatan-dawanda", sourceType:"Shop", imageVersion:"listview", autoSlide:"false", cols:"2", backgroundColorTop:"#e6e6e6", hideProductInformation:"false", sourceId:"30492127", rows:"2", backgroundColorBottom:"#FFFFFF", backgroundPattern:"", innerBackgroundColor:"#FFFFFF", uuid:"67c6f3095e" }).render(); }); jQuery.noConflict();
DaWanda - Products with Love
1 note
·
View note
Text
ActiveRecord Wats and Aaahs

ActiveRecord generally is really awesome, and makes optimizing query searches very easy. I found some quirks however, and will include some things below that seemingly have no logic to them.
In an other app I was making, I was iterating through several active record objects based on their id's, and sending a text to their associated phone numbers. I noticed it was always the first object, that received everyone's number. However I couldn't find the error until I carefully noticed it was literally the same object being "iterated" each time. Turns out I had
Product.find_by(:id) as opposed to any of the three below:
Product.find_by_id(:id)
Product.find(:id)
Product.find_by(id: :id)
I also found these interesting, results, where any integer except zero yielded the first object, with zero yielding nil. inserting "nil" as an argument returned true, as do fractions over 1. Fractions less than 1, but more than zero yielded nil, while those same numbers in their decimal forms, yielded the first alert object. for example:
Product.find_by(1/2) and Product.find_by(0.5) yielded different results.
Product.find_by(nil) returns alert, and Product.find_by(true) returns nil. Go figure!
Find_by(nil) is true?
and yet find_by(true) is nil...
Irrational arguments like find_by(2**0.5) are fine, but basic fractions aren't?
In short, while most of these arguments wouldn't be expected, I would at least want it to give an error, if the proper format isn't being used.
0 notes
Text
Who's Looking at Your Cookies?
The RESTful conventions are a handy way for sharing and accessing resources on the internet, however HTTP requests are stateless, meaning it doesn't keep track of who it's receiving requests from. This would mean, that every time you switched to a new page, we'd either have to retype our preferences, or create controllers that would redirect to different pages, as well as transport parameters/data (not even sure how I'd go about doing that!).
Cookies, small files stored locally on your hard drive are automatically supported in Rails, through enabling of :sessions. This allows the authentication of proper permissions, or saved settings through every request.
This means, that if someone can access your cookies, they can access whatever you had authorized access too. This is a problem, if you're browsing the web on an unencrypted wifi network, or not using SSL encryption.
CSRF Forgery: Because cookie sessions are triggered by specific domains, a hacker could simply email someone, an image or link, that contained proper restful commands, eg www.example.com/user/1/destroy would use your cookie to destroy an object of www.example.com.
You can prevent, this, by adding this simple line inside your ApplicationController file.
protect_from_forgery
which will automatically generate a security token for all forms in rails. If the token doesn't match the expected cookie session, the cookie will be automatically reset (i.e. you'll be asked to sign in again to authenticate).
Editing your cookies? There's a sweet Google Chrome AddOn that lets you edit, delete and view your cookies easily https://chrome.google.com/webstore/detail/editthiscookie/fngmhnnpilhplaeedifhccceomclgfbg
If you tampered or edited the cookie file themselves, the signature of the cookies would be different. The signature just ensures validity of cookie, while additionally cookies can be encrypted (automatically in rails 4 onwards) so that no one can snoop the content of the cookies, i.e. the hash inside it, eg session_id or any other key references to a database on server.
1 note
·
View note
Text
Scheduling Your App To Do Certain Things
Cron Jobs: Cron Jobs is a scheduler for Unix operating systems, using shell scripts to compile your scripts based on schedule you specified, It has a very wacky syntax of minutes, hours, days, months, (then) weeks and optionally years.
I didn’t get far with Cron Job, because it required specifically configuration for my development phase, and nothing seemed to quite work. Come to the rescue: Whenever! Literally a Ruby Gem.
and cd into your directory. run
`wheneverize .`
which will insert and create a schedule.rb file for you in your Config folder.
In my sample MTA API app, I wanted to repopulate my migration files with fresh seeds. In my seeds file, it automatically deletes the old seeds, before it gets new seeds.
What's really neat about this is, because it's a file and gem, if someone else forked your project, or if you mode between modes of production; the integration is smooth, since it's merely a ruby helper file.
0 notes
Text
Hashes Vs Arrays?
Conceptually I think of Arrays, as index based Hashes, but that couldn't be farther from the truth. Asides from the fact, that Hashes allow you to customize your key value, the way they're store in memory is different. Hashes, are literally referenced via their hash values; which make them much faster than Arrays.
If we had an array array=[1..100], and we wanted to find the index of the value 100, you'd have to iterate through 100 values, before you found the index of 100. On the other hand, hashes (as in Hash.new) are organized, by sorting out the modulo values into bins. Hashes by default start out with 11 bins, and when one of those bins starts to fill up (with a 5th element), more bins are created. The creation of bins takes up some memory/time, but overall it's much quicker, because it's able to reference to these bins and iterate through 4 bins, rather than every single element in an entire array. Because Hashes are organized, according to it's internal logic, there is no "order", you cannot append a value at the end, or beginning of a hash, like you could with an array.
0 notes
Text
Sinatra Obituary?

A review of Sinatra,
In Contrast to Rails’ Gem which is over 100,000 lines of code, Sinatra is much more lightweight at 1,500 lines. As we start preparing for Rails, we’ll see that Sinatra is not opinionated, it doesn’t any mandatory conventions over configurations (in contrast to Rails, where everything has a predefined location and framework, e.g. using Model/Views/Controller structure i.e. MVC).
That said, As you start developing more complex Sinatra Web Apps, the MVC structure is very helpful, because it isolates responsibilities, which makes testing, and workflow much handier. Though we can use any Object Relational Mapping, one of the most popular ORM’s is ActiveRecord, which is extremely opinionated eg, in naming, schema conventions but doing so minimizes amount of code you write.
Models is where most of the back end logic should occur, such as instantiating objects, and mapping them to a database (using Object Relational Mapping gems), Views is what actual website will look like, thus usually rendered into HTML, PDF, JSON with minimal logic, eg embedded Ruby inside. Controller is like a switchboard, that dictates the run-flow of the application in calling certain parts of Models or not.
Unlike Rails, because the apps/gems/api’s in Sinatra are built from scratch, most code is actually ran, so they tend to be lighter, and run more fast.
Sinatra is also described as a “wrapper” or Domain Specific Language for Rack(up) Middleware, meaning it contains the code, to help run routing requests between an app, and a server, using Rackup and the Restful Architecture (GET, POST, UPDATE etc.. over HTTP protocol).
1 note
·
View note
Text
Data Compressions: Huffman Coding
Data compression is a way of shrinking the size of a file, while preserving (most of the time) it's original content. This can be handy when your hard drive has limited space, or you want to share a file across a network with limited bandwidth.

The larger your data, the bigger percentage you save, when you compress. Part of this, is because repetition of string characters are easily abstracted. Let's dive into some code and examples:
DEFLATE aka Sliding Window Compression
As a kid, I sometimes exchanged secret messages with a friend, by agreeing beforehand on a common book (or a dictionary if you will) and we'd write messages to each other, with each word in the format of [x,y] where x represented page, and y represented the nth word on that page.
Similarly, when writing a paragraph, we could DEFLATE a paragraph, by referring to [x,y] where we start at string.chars[x] position for [y] characters.
Example:
You've got a massive document that you need to backup, and you want to minimize the amount of space it takes up, so you compress it. Suddenly, that same data only takes up a fraction of the amount it did before. But how?
You've got a massive document that you need to backup, and[23,5]want to minimize the amount of space it takes up, so[57,5]compress[29,3] Suddenly,[113,6]same data only[60,7]up a fraction of the[106,8][96,3]did before. But how?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Notice how in first substitution [23,5] means that 23 characters beforehand (starting with space character “ ” we need to copy 5 characters, which comes out to “ you “. It does not distinguish between letters, spaces etc..)
We shaved off 18 bytes using this method (each number gets saved to a byte, so this gives us about 10% compression, not bad for first part!
Huffman Code is very exciting, because rather than use ASCII representations, we reassign our own bit representation for each letter, depending on it’s frequency, with most common letters being assigned smaller bit values (e.g. 10 or 100), while rarer letters (if used at all) are assigned larger ones. This is determined through creation of Huffman trees (graph) with weighted nodes on a left/right branch(es); see below for Ruby Code and Examples.
We start off by counting frequency of each letters, in this case it;s
3: [a,b,]
2: [c]
1: [d,e]
The new bit representation of each letter, is determined by the levels (lower it is, larger bit value will be) and if it's a left branch, we assign 0, otherwise right assign 1.
A= 00, B=01, C=10, D=110, E=111. We create this graph, by first assigning weight value for each letter which we'll call nodes (see A,B for example). The next step is to combine two of the least frequent nodes. We keep repeating this process until we have one node, containing total number of characters (10 in this case).
Click here build your own custom huffman tree
1 note
·
View note
Text
PGP - Pretty Good Privacy and Surveillance
"PGP empowers people to take their privacy into their own hands. There has been a growing social need for it. That's why I wrote it."
~Philip R. Zimmermann
On Wednesday, May 14th I took off some time from my coding to sit in a historical lecture at Cooper Union, featuring Glenn Greenwald and Matt Taibbi. I've been inspired by Snowden's revelations, amongst other recent events, to study and take upon myself, necessary measures to keep my computers, and also friends secure. As a survivor of government surveillance myself, I experience the chilling effects that surveillance has, on people's ability to associate and on their freedoms of expressions. Easier said than done, even adversarial journalists have a difficult time implementing measures to keep themselves safe; evident by Greenwald's early reluctance to use PGP.
NSA scours internet looking for people using PGP encryption, but if millions do, impossible for NSA to target people for that ~@ggreenwald
So how does PGP work? Before we dissect public/asymmetric encryptions, we need to understand symmetric encryption (a key that both encrypts and decrypts). If you have physical access with your contact/target (e.g. your own computer, or physically traveling with a "One Time Pad" the way the KGB did, symmetric encryption can be a secure means of communicating. XOR Encryption is relatively simple, using ASCII representation of password (key), and adding it mod 1, to each of the characters you're encrypting. Knowing this, you could use frequency patterns to look for common characters like `Space` and `e`. One Time Pads, in theory offer a work around to this, with truly random, enormous encryption keys, that are used only once (or else cypher text could be compared with others). The challenge, mathematically, is to produce truly random, "one time keys". There are better asymmetric encryption standards such as AES,

That said, it is very inefficient, for initiating email contact with people you don't have a physical way to reach; and in order to give them an encryption key, you'd need a secure way of that; additionally, you wouldn't be able to validate identity of recipient, even if the key was transmittable. To the rescue, are public keys, or asymmetric encryptions and digital certificates, which incorporate hash functions to ensure data integrity (i.e., that no one tampered with data, or switched keys while the data was en route.)
While not proven, so far it's been very difficult for computers to find the factors of sufficiently large numbers, however it's quite easy to multiply two numbers together, and given one of those factors, it's easy to find the other. Because public keys, can be seen by anyone, they tend to be larger, but they use different algorithms so private key may be more secure, despite being a fraction of the "bit" size.
Signatures -- Hash Functions, we've been using Hash Functions, to ensure the data integrity in our Git program. In essence, hashes are one way functions, that are created as a way of ensuring both that data hasn't been compromised; as well, as way to NOT store vital data, like passwords in plaintext in a database, but rather compare their hash outputs, with a hash interpreter when you sign in an account. From the hash outputs themselves, you cannot ascertain there original unencrypted form.
In short, particularly if you are a high target, there are many vulnerabilities, that need to be taken into consideration, such as whether you trust the strength of encryption you're using (assume there aren't backdoors installed), authenticate the validity of person you're communicating with, etc.. https://www.gnupg.org/index.html is a good place to start:
Force of authority is derived from violence. One must acknowledge with cryptography no amount of violence will ever solve the math problem. ~Jacob Applebaum, Wikileaks Affiliate and TOR developer.
Below is image of Aaron Swartz, a Brooklyn hacktivist who took his own life on January 11th, 2013, after a relentless federal prosecution under CFAA (Computer Fraud and Abuse Act -- pre internet laws from 1984)
I hope to write future blog posts about various ways in which the NSA, and other agencies, both public and private exploit people's privacies for sinister purposes.
1 note
·
View note
Link
The arguments for Optimism(Personal?,Temporal?,specific?) and how we rationalize success/failure of situations, is dependent on the attributes we inconsistently rationalize them with.
While we're not always able to control our environments, or opportunities; we do have agency in how we rationalize those situations, as agency to struggle internally with how we respond. More specifically, when receiving feedback; there's question of who/what "should be held accountable" and what the intentions of said critique/feedback are, and whether it's temporal or static. At the very least, in how we choose to explain both good and bad news, should be consistent, because of said conditions. That is, when you're doing well academically; it's because you were prepared, studied etc... and when you don't, it's because you weren't prepared etc.. Likewise, if good things only happen out of luck, then so too should bad things happen out of luck. By shifting perspective, on how we justify things, we can also be less arrogant and hard on ourselves, when things aren't going as well.
0 notes
Text
Thank Goodness You're Stupid!
I just completed my fourth week of pre work, in coding preparations. Learning git control, MySQL, Ruby and Rails. The essence of coding, is fixing or adapting code that doesn't work. There's an elegance and collaborative tune to it, but at the end of the line, if it doesn't compile it doesn't compile. You're constantly reminded, that you're inept at telling the machine the very exact steps you want it to do. No longer, can you blame someone elks for a broken system, because you ARE creating that system.
"Being smart" or qualified, has been a non motivational factor for me, because I'd never feel like I achieved those states. On the other hand, fueling my love and desire for learning, curiosity; has kept me going, especially because everything I learnt, was recursive, in that it built on top of previous foundations I knew.
0 notes