| --Relational Database | |
| --1. You are the proud owner of the MySQL database schema below. Write a query that will return a result set of (plan name, | |
| -- price, and interval) ordered by price from lowest to highest. | |
| SELECT Plan.name, Pricing.price, Pricing.interval | |
| FROM Plan, Pricing | |
| WHERE Plan.id=Pricing.plan_id | |
| ORDER BY price; |
| Web forms always require special attention when it comes to programming. From the user standpoint, it is a place where we are | |
| being asked to partipicate (sometimes reluctantly) and interact with an application, often to provide information that can be | |
| redundant. | |
| I have learned that in order to ease the user experience, forms need to be well designed while conveying a feeling of | |
| familiarity; very informative (being explicit about the required field and the characters needed to create a valid password); | |
| offering proper feedback (intelligle error and not too abrupt error messages, state in clear manner the reason why | |
| the form can not submitted). Betwween the forms I have implemented for some personal projects and the contract work that I do | |
| with Independant Curators International, I have always treated web forms with a special attention by using my personal | |
| experience. |
| Having a tool to visualize activity allows the company to be more prepared for the unexpected bugs. I think using | |
| database triggers could be a way to anticipate or at least be more responsive when it comes to those bugs. For instance, | |
| we could implement a trigger on some specific fields in a form and every time any given field is submitted or modfied, | |
| a separate row or a table could be created with information regarding the field targetted a timestamp and the user id. | |
| This would allow to have a simple changelog. We could go further by usign websockets and get instant notifications from the | |
| server for any given trigger/change. |
At the top of the file there should be a short introduction and/ or overview that explains what the project is. This description should match descriptions added for package managers (Gemspec, package.json, etc.)
Show what the library does as concisely as possible, developers should be able to figure out how your project solves their problem by looking at the code example. Make sure the API you are showing off is obvious, and that your code is short and concise.
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <meta charset="utf-8"> | |
| <meta name="viewport" content="width=device-width"> | |
| <title>JS Bin</title> | |
| <style id="jsbin-css"> | |
| * { | |
| box-sizing: border-box; | |
| font-family: sans-serif; |
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <meta charset="utf-8"> | |
| <meta name="viewport" content="width=device-width"> | |
| <title>JS Bin</title> | |
| <style id="jsbin-css"> | |
| * { | |
| box-sizing: border-box; | |
| } |
| <!DOCTYPE html> | |
| <html> | |
| <head> | |
| <meta charset="utf-8"> | |
| <meta name="viewport" content="width=device-width"> | |
| <title>JS Bin</title> | |
| <style id="jsbin-css"> | |
| * { | |
| box-sizing: border-box; | |
| } |