Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
If you just start typing a person name in the Facebook search box(displayed in blue upper bar on your profile) then suddenly within a fraction of a second search results appear and they comes much more faster if that person already exist in your profile.
so i just want to know that what is behind this search.i mean to say that which software tool and algorithm they are using for it.
i know that no one other than Facebook can explain exactly about it thats why i am just asking to give me an idea about that.
i am sure that they are using something which is open source.
The response is an autocomplete Ajax form, but this is not really the question. The key question here is how fast can you search in a text field. Facebook splits this into 2 parts. First they search in the list of your friend which is a cached and relatively rarely changed file containing 100 to a 1000 entries. This is quite fast. The other thing is to search for a name in ALL Facebook, which means I guess 1 billion names. This is a little more tricky, but I guess they have them splitted and indexed by letters or letters combinations. For example:
// search query Alice Cooper
A ... they give you a list of A like names Alina, Ana, Alice...
Al .... they limit it to Alicia, Alice, Alina ...
// and so on
Probably after a 3 letters they are starting to do a search, but not in the 1 billion rows, but in a limited subset of your 3rd level friends and probably increasing it each time.
Probably your query is never compared with the whole table, and there are definitely cached levels or recalculated queries for most of the common names.
This is in terms of technique. In terms of technology take a look at Solandra, a search engine build on top of Cassandra which Facebook is using, though I cannot confirm that this is what they are using, but just to give you a research direction.
I assume the underlying technology is AJAX, with some caching mechanism that increases performance for profiles in your friends list.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Looking for some advice... just finished a ETL pipeline where all data ends up in Amazon Athena. The data is produced via the click stream of high volume mobile apps (so essentially it’s lots and lots of raw events). I want to build a number of dashboards for the business that show different metrics/KPIs depending on the requirements. However, since we’re talking about huge volumes of data I’m not sure the best way to do this? Here’s an example:
I want a dashboard that shows all the MAUs (monthly active users), along with certain pages that perform particularly well and the most popular navigation routes through the app. My thinking is that I’d want a custom query per graph I.e. one query that is counting the distinct IDs each day (and then refreshing every 24hr)... another query for a graph that produces a breakdown of counts per page and truncates... etc
The main reason for thinking this is otherwise I’d be pulling in huge amounts of raw data just to calculate a simple metric like MAUs (not even sure extract would work - certainly wouldn’t be efficient).
Is this completely the wrong approach? Any suggestions/feedback?
Thanks in advance!
It sounds like you have multiple unrelated SQL queries that you want to run once per day, and update in Tableau once per day.
There's always a pull-push between the processing at the source and in the visualization engine.
Set up a Tableau server extract for each Athena SQL query. Build your dashboards, and schedule your extracts to refresh daily. Like an OLAP cube, this will process all the aggregates your dashboards need with the refresh, for better dashboard performance.
Alternatively, if you feel you don't need all the detail in Tableau, then build your aggregates in SQL, so that your Tableau data sources are smaller.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
For me, the toughest part of making app was finding ways to make tastypie work in undocumented area.
I'm listing stuff I find it hard about tastypie below.. (It's been a few month I actively worked with tastypie-related code. so my description might not be perfect)
It's mostly about related-field management.
Suppose resource_a has related field resource_b.
When user create a resource_a_instance with resource_b_data,
if resource_b_data is dictionary data, tastypie creates resource_b_instance and creates resource_a_instance. (I find this is magical.. We can only control 'related_name' to something.)
if resource_b_data is resource_uri, tastypie uses it as foreign key.
So either, client has to send resource_uri only for resource_b, or server has to modify the resource_b_data.
when client sends 'patch', tastypie actually get all the fields to construct the corresponding object, and do 'put'. and it has to read related fields as well iirc.
I encountered a bug dealing with image field update.
https://github.com/toastdriven/django-tastypie/issues/1018
tastypie dehydrates and uses it to update the object, dehydrating image-field gives url not the path and it causes the problem.
dehydrate is for preparing data for user consumption, and it's used for updating data... I guess it's a big problem.
I'd like to send subset of defined fields per requests, but it doesn't seem to be there's a cleaner way.
How do I paginate the many-end of a related field? (with the pagination related meta field included)
#3, #4 are just examples, when I have to do something beyond the doc, it's hard to know how to proceed. I guess you have to read the code carefully..
I hope if someone could show how the above problems are solved in django-rest-framework world as well.
I've seen comments about django-rest-framework having well-thought-out structure and wonder if it indeed offer easier solution on above problems.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I am on a dedicated project. It is an e-commerce website. That website is in 3 languages and runs on 7 domains at the moment ( .com/.us/.au/.fr/.ru/.ca/.nz ). It has been running since forever so very old logics and processes are still being applied into it as big changes cannot be made easily. Now, it has 32 email templates for every domain related to purchase etc. At the moment if there is even a little change a designer has to do it 32x7 times. It is highly redundant. I proposed my development team to make master template for each domain and seeing as only EN FR and RU will need different templates so i will have to only make changes 3 times. Now, i am baffled as to how the backend for that would/should be, as in, the header, footer, navigation etc will all be coming from cms/database where a non technical person will enter text to make changes. Can you please give me an idea as to how should i approach this ? The project is in asp.net.
Sorry for the long description but i am really confused as to how the data entry person will enter all the information related to emails and other things that will need this sort of implementation. Sorry for my english as i am not sure myself if i was able to clearly state the issue, let me know and i will explain it again. Thanks.
If you use a proper CMS (e.g. Kentico CMS) that stores content in a database, the backend depends on how the CMS organizes the data in its database.
Learn about how the content maintainers will organize the language-dependent content (in the way that you are already thinking about it - content for what defined page sections per language)...and how that will translate into your CMS's underlying organization of the data.
Start small, and be systematic - on the input end (i.e. how a content maintainer will go about doing their part) and on the content-consumption end; try to make one simple portion of the site that works with so much redundancy today...work without it; and go from there.
For example, focus initially on one simple defined section in one page with content for each language. With that clear, consider a more complicated section that requires organization of content for each of its content areas. Then expand to multiple pages, considering different page types that may have different defined sections (and may already be clear from different master pages they employ).
For email templates in particular, I have successfully used a CMS-maintained Smarty template per transactional-email type (e.g. order confirmation, shipment confirmation etcetera) for e-sales - even with ASP.NET being the primary technology on the team. You may need # of email types * # of languages templates, but it sounds like such an approach could work.
Also, consider that your CMS very well may expose services whereby you can get the content, such that you do not really have to be directly concerned with how it organizes the backend data.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I've been searching a long time for some guidance or examples of web form design of large forms (dozens of fields - maybe 50+) for a user base that will be trained on the application.
99.9% of the guidance seems to be geared toward "accessibility" or "intuitiveness" which are, by all means, valid goals. The issue is that a form that will be used on a one-off or infrequent basis by users who will likely be encountering it for the first (or only) time has much different considerations required compared with a form for data entry to a business application that will be used repeatedly all day long by users who are trained on the app.
If I'm designing for a one-off (say a sign-up form) then I want to focus on designing the form so that the user can't help but flow naturally through the steps and end up completing their goal and feeling all warm and fuzzy.
If I'm designing for an experienced user that will use the form 20x a day, they are going to want it designed to minimize the clicks and navigations, etc. They don't care [as much] about looks or flair and subtle cues to help them work through the form. They know the form like the back of their hand and just want to be able to enter data as quickly as possible and see as much as possible in one view.
The requirements that I'm getting from the users is that they want to see "everything" on one screen. They don't want to have to scroll. They want to minimize clicking to other pages to continue working.
Does anyone have any suggestions/links/dire-warnings??
Thanks,
Dave
My instinct is to tell you to break it up into sections the user can navigate between, to minimize the amount of continous data entry they have to do, as well as keeping the sections you have to validate to a minium. Get all the way to the bottom only to have to scroll back up to the top... annoying!
Since you want a large form, however, my suggestions are:
Validate as you go. As soon as a user leaves an input or section let them know everything is okay. Don't glue them to a control though, use visual feedback (like backgrounds going red or similar).
Don't lose that page! Use whatever technique you can (including background submits) to store the user's states. Funnily enough, a certain user driven programmers community website does that...
Tab navigation! Set the tab order! Your keyboard wizards will love you
Although you might want to jam as much as possible onto one line, don't. Keep good spacing and vertical navigation - people are used to scrolling vertically, and good spacing makes things readable.
There's lots more, but, as you might expect, there's an even better answer, here
We touch on the key drivers for designing forms for high-usage, trained users in our book "Forms that work".
The key points are:
Try to cram everything onto one page, as described. Having to click from screen to screen becomes very tiring very quickly when you're using the same form all day every day.
If you must separate off some items, do extremely careful observational analysis to discover which items are genuinely used rarely. Put those ones on the 'extra click' screen.
Abbreviate the labels ruthlessly, taking advice from the users on what abbreviations are required. They'll rapidly stop reading the labels anyway, working mostly from the absolute position of fields relative to each other...
... which means: don't ever allow fields to move about. Make sure they retain their absolute position; this is essential for speed of completion
Make sure that the form is entirely navigable using keystrokes alone. This is essential for speedy completion by experienced users
Find out where the answers come from to go into the fields. If they are typing in stuff from another document (it does still happen, believe me) make sure that the field are arranged in the same absolute positions to each other as is shown on the layout of the document they are typing in from.
Don't worry too much 'intuitiveness'; these people are going to be trained.
Bounce rate is completely irrelevant, so you can skip any advice you see about 'conversion' or 'bounce rate'. These users don't have the option to go elsewhere and do a different form.
Email me directly if you'd like to discuss this in more detail: Caroline Jarrett. More contact details on Forms that work - our book's web site
I've got two suggestions. Keyboard and consistency. The one thing you want want when using a form like that so often is the ability to do it with your eyes closed.
The focus should be at the first field, from there on it should take the exact sequence if keystrokes to fill and submit the form every time. Normally this means and type till all fields are filled after which you can press enter to submit.
And try to get audio feedback in there when something goes wrong, often people type blind and have their eyes on a piece of paper and not on the screen, a simple beep to tell them to look at the screen really helps.
hmmm,
I understand that the client wants it done on "one" page however if this will rarely be used like you say I would give it to them in bite sized pieces or your bounce rate will go through the roof.
here are some links using jquery to forms similiar to what I am refering to:
http://www.thecodemine.org/
http://cardonadesigns.com/wordpress/thoughts/ajaxish.php
http://jquery.bassistance.de/validate/demo/multipart/
to name a few.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I've just picked up a contract to sort out a vipers-nest of e-commerce websites that a previous 'developer' left for one of my clients. There's about a couple of dozen of them using a custom shopping cart and CMS system that's too embedded to dump and works well enough, but desperately needs cleaning up, re-factoring, and bug fixing, so a reasonably substantial recoding job.
As part of this my client is desperate to ensure the best search engine placement he can get. Like many developers I've a nodding acquaintance with the idea, but no real knowledge, and it seems that it would be helpful to get up to speed on this so I can build appropriately into the code.
So can people advise on useful quality resources - books, websites, blogs etc? I do not wish to obsess over every last detail on this (he can use a specialist if he decides to pull every last ounce out - although I've always regarded such as little better than snake-oil peddlers), but I would like to build code and reconfigure templates in a manner that helps rather than hinders placement.
Look at Wikipedia with styles off. See how they order their content? See how they use correct tags to label the content? These are the keys to long term success.
The most important SEO advice is to create a semantic, logical site. The content comes first and is ordered by importance. Use the correct tags, don't do tables. Then apply styles. Then apply script to make it fancy. (Like Tomas said)
Know the difference between what is content (pictures of your products) and not (your logo tiled on the background). Basically do your best to present good content in a good way. You can't game the system for long term gains.
This will give you long term placement. Most SEO companies just do tricks or links farms or worry about keywords and meta tags, so they are temporary at best. I think it is good to assume that Google works just as hard to drop that crap from it's index as the SEO marketers do to include it.
According to Google's patent
Age of domain.
Important sites that link to you.
Content. Make it real and accurate.
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=20050071741&OS=20050071741&RS=20050071741
A main concern when thinking SEO should always be usability. Make sure the mark-up is semantic, make sure the site works without javascript, css and images - in other words, make sure that 'low-level browsers' are able to read the contents of your page. Think of optimizing the site for a screen reader for the blind and visually impaired, and you will automatically cover the search engines, because that is exactly what they are - blind browsers.
A standard no-no is a table layout, mainly because it does not order the site content by relevance. To a human being reading your site, it is no problem looking two inches down instead of at the very top of your page, but the screenreader reads the code, not the visual view.
Thus, you should make sure that you have the important things - a high-level heading (preferrably <h1> or <h2>), the main menu (in a <ul> list) and the content in divs at the top of the source, and less important content (the logo, banners, quickmenus etc that aren't really crucially needed to be accessible) further down. You are always able to re-order where the stuff is actually shown in your css.
New tag to use called CANONICAL can now also be used, from Google, click HERE