WikiVert (auto-search for all points from WikiTravel-like text/attractions list)
It’s quite curious how things turn out – the initial idea for the resource was completely different (well, who knows, I might get to it some day after all) – but hey, “whatever works”, right? Hopefully these tools (however immature and weak they are) might be useful to someone (and most hopefully to myself).
Well… bon voyage, there’s not much else to say really.
It’s a script (in AppleScript) that goes through all Apple Mail filters and converts them to Sieve filters, so you could go server-side on email filtering
The answer is, as usual, “because I’m lazy” – I’ve accumulated a fair bunch of Apple Mail filters along the way, and converting them manually wasn’t much fun. And I found no working option to convert it on the Internet.
NOTE that this is validated with a quite limited use case – in my filters, I mostly match against subject and sometimes against CC/To, so it definitely has some issues with other fields. Please review / try loading the results first and don’t disable all your Mail filters right away.
Exporting Mail filters
Just run that script – it will ask you if you want to use disabled filters as active (useful to re-export after you have already disabled Mail filters), then if you want to disable Mail filters (useful when you’re certain in your Sieve filterset), and then where to save the results.
Was it fun?
Well… the answer is “look at the code”. On the one hand, writing in AppleScript is quite unlike writing in most of the “conventional” languages – some constructs are very different, some seem more natural, others more awkward. On the other, loops management reminded me of programming Turing machine – I mean, using THIS as “continue”, really?!
So to conclude – I think it was, as any unusual experience is fun in it own (however peculiar) way. And it’s the “proper way” for the case – you deal with official API, not parsing the XML (which I could, because Mail rules are stored in XML files) because there’s no way to foretell where the source would move or how its structure would change eventually. Mail API is way less likely to do so.
A neat approach with many benefits. Two things to mention:
this is a concern when the common replication technique starts being a PITA (with GTID, promoting a new master in MySQL shouldn’t be a problem). So this is not what you should rush for for your 2-slave setup
this approach applies to pretty much any replication task – not necessarily MySQL, not even necessarily DB replication at all
You can have this benchmark run forever, or you can specify a specific period of time. To set the duration of the test, use the -t NUMm option. The NUMm format is a representation of time. Here are some time format examples:
-t60S (60 seconds)
-t1H (1 hour)
-t120M (120 minutes)
To demonstrate running a benchmark, let’s run Siege against this blog:
siege -b -t60S http://blog.remarkablelabs.com
and then also “user emulation”:
When creating a load test, you should set the -dand -c NUM options. The -d NUM option sets a random interval between 0 and NUM that each “user” will sleep for between requests. While the -c NUM option sets the concurrent number of simulated users.
Here is an example of a load test of a Heroku application:
and you could use custom headers (think cookies) with -H.
And what’s even better, it’s widely available – I’ve installed it on Mac through Ports (although it’s on brew as well) and then unpacked it from RPM on my GoDaddy SSH shell account (because I couldn’t just go and install it there). It worked well in both cases.
I was just reading a security article when I realized that it’s a fairly interesting data that is actually rather valuable, but its representation is completely wrong. And it’s mostly because of extensive pie charts usage. There’s an excellent review of what in particular is wrong with pie charts (in many ways), so I won’t repeat that – I’ll just do a short “case study” here.
So let’s have a look at this one example:
Note that I copied it with a part of URL, and that’s for a reason that I’m gonna start the list with:
it doesn’t fit on screen (chart subject couldn’t fit at all), and my Air is not the smallest screen example. Yes, legend could be rearranged, but…
chart needs a separate legend anyways. You just can’t properly tie labels (not even numbers) to slices – all attempts are futile. Which makes it a mandatory
to travel back and forth between slice size, its location, number and legend (and scroll if your screen is not huge). And then my favorite,
colors! Every chart that needs more than few (like, 4) colors is a bad idea. I cannot tell Ukraine from Vietnam here (no one needs to know what’s under 3%, but let’s leave that aside) and India from Kazakhstan color-wise. And I’m not even color-blind in this spectrum! (although I am in red-green shades, so I feel for others)
And now what the above essentially is:
yes, it’s THAT bloody simple! And it’s a very fast approach. And you can easily reduce sight travel (and improve precision) like this:
That’s it! One color, tightly packed (yet not crumpled), neat and straight to the point. Ain’t no jolly colors, true that – but it ain’t no lollypop fare ad either.
So… just don’t use those pie charts, there’s pretty much no use case where they are better that other visual data representations. Not unless it’s actually a tasty pie you’re sharing, at least.
And while we’re at it: LibreOffice charts widget sucks. Even GoogleDrive, with all the simplicity, shines (usability-wise, at least) in comparison.
This was hanging around in my Keep for quite a while – right till I realized that I need it somewhere for a quick reference, although it just messes my Keep flow. Thus posting it here in a “JFTR” fashion.
Data access latencies:
L1 cache reference ……………………. 0.5 ns
Branch mispredict ………………………. 5 ns
L2 cache reference ……………………… 7 ns
Mutex lock/unlock ……………………… 25 ns
Main memory reference …………………. 100 ns
Compress 1K bytes with Zippy …………. 3,000 ns = 3 µs
SSD random read …………………… 150,000 ns = 150 µs
Read 1 MB sequentially from memory ….. 250,000 ns = 250 µs
Round trip within same datacenter …… 500,000 ns = 0.5 ms
Read 1 MB sequentially from SSD ….. 1,000,000 ns = 1 ms
Send 1MB over 1 Gbps network ……. 10,000,000 ns = 10 ms
Disk seek ……………………… 10,000,000 ns = 10 ms
Read 1 MB sequentially from disk …. 20,000,000 ns = 20 ms
Send packet CA->Netherlands->CA …. 150,000,000 ns = 150 ms
MySQL Storage Requirement per Data Type:
TINYINT – 1 byte (BOOL is an alias for this)
SMALLINT – 2 bytes
MEDIUMINT – 3 bytes
INT, INTEGER – 4 bytes
BIGINT – 8 bytes
FLOAT(p) – 4 bytes if 0 <= p <= 24, 8 bytes if 25 <= p <= 53
FLOAT – 4 bytes
DOUBLE [PRECISION], REAL – 8 bytes
DECIMAL(M,D), NUMERIC(M,D) – Varies
BIT(M) – approximately (M+7)/8 bytes
I’ve mentioned this collection of interface tips&tricks named “Good UI” already in a direct post on FB, but thought I save some things “for latter use” here. With my thoughts applied. That article, it’s quite a long read – I usually don’t go for articles like “X reasons of doing something” where X > 10, but this one is rather justified – and you don’t have to go through all of them in a single leap, you’re free to stop when your morning coffee is done and come back next morning.
That said, below goes a list of personal thoughts on each point. Wanted to make sure I actually read those, not scrolled through.
A note: all these things are improvement points, one should never aim to fulfill any portion of this list as a necessary prerequisite to launch a product. If you have the working thing – throw it in and go through the lists like this afterwards, applying whatever is the fastest and cheapest thing to do first, or what you see (not oversee) users struggling with.
One-column layout. This is generally useful when you have a stream of information (like that article itself), although extra column with related article or hierarchy or breadcrumbs or tag cloud could still be useful. Just don’t put any content there.
Gifts like ‘first month free’ – sounds fair, I’d go for a free month. Or first N free deliveries. Or first X movies for free. Or whatever. Usually I don’t follow up (like with Amazon premium), but that’s mostly because I can’t appreciate most of the benefits due to regional restrictions. BTW on giving gifts: make sure customer can claim it before announcing it. I despise Netflix for their “free month” they advertise to everyone while it’s there for US folks only.
Merging similar functions. That’s renowned Occam’s Razor, no comments there.
The social proof – I actually find it annoying and ridiculous. Reviews at the 3rd-party site (like appstore, hotel search, gadget review site) – fine, reviews at the company site (however pulled from social networks) – no go. You want to tell about yourself, you describe what you/you product do. Few sentences, strict to the point. Links to advanced docs/tutorial. Short example, if relevant. That stuff.
Repeating primary action – might be OK if not overused. Don’t really have any opinion here.
Distinct clickable/selected styles – this one’s obvious, but still often neglected. It’s very important to distinct clickable items, as well as marking selected. What’s more important though is keeping it common, something audience is used to. Think buttons, blue colors.
Undos. This is big, one of the things I love Gmail for. Although worth saying “consider frequence” here – if the button is to be pressed once in a week, there’s no need to bother with undos – annoying confirmation would do just fine.
Telling who the thing is for – I guess it makes sense.
Being direct – sure, why not. I mean, it’s always better to state something than question or get lost in options. Some might disagree with your statement, but most will take strong opinion as “I guess those folks know what they’re saying”. Important thing here: you must know what you’re saying, there should be concrete base for that.
More Contrast (for key elements) – definitely a good thing, just don’t go extreme.
Showing where it’s made – it, well, depends. On where it is made, just as well as on the audience it’s been targeted at. Don’t want to throw any examples in, I guess you can imagine a handful yourself.
Fewer form fields – indeed so. I always wonder why would image sharing site need my home address. I’m making it up, but some cases are puzzling indeed.
Expose options aka radiobuttons vs dropdowns. It’s relevant to some cases, irrelevant to others. Just consider how many steps (or time) would it take customer to the next page (scroll/search included). Meaning, you can’t just unravel all items from country list on a page – user would still need to search for the country, but select-as-you-type wouldn’t work, and getting to other elements would require extra scrolling.
Endless Scroll – personally, I think this is a brilliant example of how technically sexy feature was considered useful “because it’s so cool”. While it’s everything but. You have many items to show? Solve it the other way. Filters, tags, classes. Explicit “show next page”, after all. Just don’t load more when no one asked for that. It’s like caching – it looks attractive and sounds simple, but there’s so many edge cases that it’s actually efficient in, like, 5% of cases. Or maybe even less.
Keeping focus – let’s see. When I see a link within a text I read, I open it in a new tab. And then I contemplate whether to go read that one first because it might influence the current page understanding or read that later because it could just add some extra points to the content after I consume it. Yet I often use this approach myself – call it a habit or a crucial hypertext principle. Links are important – but there’s sidebar, “see also” or other similar approaches to have references around. All in all… as usual, use it but don’t abuse it.
Showing state – essentially, displaying item’s status. Quite useful.
Benefit button, or droolwords. I think that’s cheap and filthy. There will be more of this, and I’ll shorten them as “drooler”.
Direct manipulations – displaying actions for current element only (and within its scope) is indeed convenient.
Exposing fields, or add actions to description – it’s pretty much shortening the number of steps to conversion. Some common sense on the number of inputs should be applied, but generally reasonable.
Transitions. Well… just read the description. OK, but minor.
Gradual engagement – starting with some partial involvement is “sorta” OK. It requires some considerations, like saving the steps taken and current position for limited time (because if user took 5 steps out of 8 and then came back two days later, he/she wouldn’t remember those 5. So… I’d say it sounds like a lovely tech challenge, but not very beneficial (unless proven by an experiment). I had some experience with this approach regarding Moto G, but never bought one.
Fewer borders – this heavily depends on general visual approach and type of the product. If you’re building a bugtracker or some other element-rich tool, you need borders.
Selling benefits – drooler, buzzwords.
Design for zero data – there’s a sticky phrase in there, “A zero data world is a cold place”. Love it. But the point itself is very fair – considering the starting point, a blank page, is very important.
Opt-out instead of opt-in – that’s up to you. It’s dirty IMO, but no one would really opt-in for a newsletter. I mean, nobody. So… I immediately unsubscribe from everything I receive, but all the sites are doing it the opt-out way anyways.
Consistency – well, yes, sure. This could actually be merged with #6. And #3.
Smart defaults. Weeell… no. I mean, what could you actually guess? City and country, maybe. But that’s about it – I’d rather fill in blanks that thinking why those are pre-filled and whether suggestions are correct (and they would mostly be not, and no matter how slightly).
Conventions – add this to #27 (and #6, and #3). It’s all about common experience, least astonishment. That’s a link within a text, is it not? =)
Loss aversion – that even sounds like another drooler, which it definitely is.
Visual Hierarchy – OK, but make sure you don’t take your customer away from the page before he/she got through all the important points. Or do it asynchronously, so customer would stay on the page while still doing things along the way.
Grouping related items – see #27 and other recursive points.
Inline validation – frankly, it puzzles me why people are still doing it “press-submit-to-see-you-did-it-wrong” way. It’s very annoying, especially (should I even mention it?) there’s a password involved. Which is, of course, discarded when validation stage is not passed. So yes, I strongly second this, should be at the top of the list.
Forgiving inputs – yes and no. Phone number fields should definitely accept many formats – but it’s quite easy to parse that. However there are many cases when it’s not relevant – it’s easier to error our (the #33 way, please) than auto-assume something.
Urgency – pure drooler. To clarify: I’m not saying this won’t work – in fact, it might work extraordinary well. I’m just against this sort of tricks, I reckon it’s dirty. IMHO indeed.
Scarcity – ditto.
Recognition – that’s often neglected while being a source of a considerable pain. I often struggle with what I should enter to some field, and dynamic suggestions are of no help.
Bigger click areas – this is essential, I don’t really understand why it’s #38. Should be #3, at least – it’s very cheap yet very effective. Aiming is a problem, especially in laptops/mobile world, which is expanding tremendously.
Faster load times – it’s rather about keeping people busy while page loads. Or doing async loads. That’s dubious – people tend to wait till something is over even though they have options to adjust while they wait. So… just make it snappy.
Keyboard shortcuts – as note says, do it if you have a lot of returning customers that spend significant time on your page. I use Gmail keyboard shortcuts a lot, I think they’re brilliant. But I don’t use Facebook shortcuts (did you know there are some?), because my use case there is mostly “scroll it down”.
Aaand… we’re done here! Playing critic is not that bad after all when you got something to say. have a nice weekend!
This is an extra brief scrape of a net communication layers – just to keep it around to look at. To understand the difference in Layer 4 / Layer 7 DDOS attacks.
7 – Application Layer. Constructing appropriate data that another application that supports same protocol would understand. Generally by using “Layer 7” term it’s common to combine layers 5-7.
6 – Presentation Layer. A bit less fuzzy – represents compression, encryption, encoding etc.
5 – Session Layer. Generally to establish a bond between sides for further communication. Quite fuzzy.
4 – Transport Layer. TCP, generally. Establishes and manages connection, controls flow, retransmissions. TCP connection: client sends SYN, server responds with that SYN and new ACK, client sends over that ACK and a new ACK.