    
|
|
|
|
|
The process of receiving payments over the Internet has steadily improved over the years. The people behind PayPal started the revolution in 1998 — later selling to eBay in 2002. A year after that, I co-founded TypeFrag, where we used a very popular payment processor called Chase Paymentech to handle our transactions before adding PayPal as an option four months later. Chase Paymentech is still popular, but it’s not viewed as cutting-edge by the current tech startup crowd. To say our billing flexibility with Chase Paymentech was limited back in 2003 when TypeFrag was founded would be an understatement.
After I sold TypeFrag four years later, we still used a combination of Chase Paymentech and PayPal at Carbonmade, my second company. That combination was the standard among tech companies at the time. There were other options, but nothing all that much better, hence it wasn’t worth switching. Then in 2007 a new company called Braintree promised better integration and more control over your customer list. We saw a lot of great companies like 37signals championing it. After talking to their sales people over several conversations, we switched to Braintree. Braintree was beginning to win huge favor in the tech community as the processor for fast growing startups. Today, six year after they were founded, their customer list includes huge companies such as Uber, Airbnb, GitHub, and Angry Birds.
Braintree has been quick on its feet and continued to adapt its technology to the changing needs of startups. For example, they saw that the New York company Venmo was taking off in processing mobile payments and quickly scooped them up in 2012 for a $26.2m. Then on September 26, 2013 eBay purchased Braintree for $800m to fend off their major challenge to eBay’s PayPal. I think Braintree could have held out and tripled their value over the next few years, but it’s close to impossible to turn down that kind of money when you’ve only raised $69m.
A few years after Braintree, the payments processing world saw a new entrant, Square, which was founded in 2009 and released their Square Reader for people and small businesses to accept credit cards through their mobile phones. Moving from 0 to 600 employees in four years, with a rumored IPO in the works for 2014, Square is well on its way to revolutionizing mobile payments. Whether they get into the online payments game to compete with Chase Paymentech, PayPal, and Braintree is too early to tell, but I’d bet that they will.
Until Square, all of these payment processors shared a common fault: they were painfully difficult to set up. Even in 2013, Chase Paymentech, PayPal, and Braintree required a lot of engineering expertise to get up and running. Not only that, they required a lot of paperwork, including scanned driver’s licenses. Then came a change. A new payment processing company called Stripe burst on the scene in the last few years, having been founded in mid-2010. Stripe’s departure from its predecessors is that for a slightly higher fee they require a lot less paperwork and — more importantly — make it incredibly easy for developers to drop in code that gets payments running in only a few hours. Stripe is what we use at my new company Uncover. Their customer list is impressive, including Rackspace, foursquare, Squarespace, Shopify and many others. That said, when our payments volume grows to a larger scale, we will be switching from Stripe to Braintree, as Stripe takes seven full calendar days to release funds to you. That’s a long time to be without your money when you’re a small business and you need cash flow to keep going. Braintree releases funds in two days.
Payments processing will continue to evolve as mobile becomes an ever more popular way to accept payments. The one thing for sure is that it’ll become easier and easier for a company to accept payments over the Internet.
The post A Short History of Payments Companies appeared first on Treehouse Blog.
]]>|
|
|
|
|
|
When she began her college search, the Honorable Wanda Keyes Heard ‘79, political science, knew very little about UMBC. But when she and her family — then living in Long Island, New York — returned from a visit to schools in the DC area, they decided to stop by the new university in Catonsville. That chance decision would change Wanda’s life.
“I fell in love with UMBC,” she says. That means a lot coming from Wanda, whose father Sterling Keyes, was a veteran educator and civil rights activist who impressed upon her from an early age the importance of education. And so she came to UMBC, where she would study political science and launch her career as a lawyer and then Baltimore Circuit Court judge.
When Wanda lost her father a year ago, she found herself making another decision about her future–the decision of what to do with her estate. In honor of her father’s legacy and her own experience at UMBC, she decided to establish a planned gift to the university. “When you leave the earth, you can’t take it [money] with you,” she explains. “What better way is there to honor your life than to give back? I know UMBC will make good use of the money.”
Wanda’s decision isn’t surprising. Throughout her career as a judge for the Baltimore City Circuit Court, she has been paying it forward. She’s an avid supporter of UMBC’s Second Generation scholarship, and she’s also given students–many of them from her alma mater–the opportunity to gain invaluable career experience as interns in her office. It’s that kind of experience that rounds out an education and launches careers.
As Wanda is quick to tell you, UMBC was truly where her life and career got started. “I received an excellent education there, and that set me on the road to law school and being a judge,” she says. “Once UMBC has put its print on you, you can do anything you want to.”
In Wanda’s case, that print was indelible, and was made by her experiences both in and out of the classroom. Wanda was active in the Student Government Association, joined the Zeta Phi Beta Sorority and worked as a Resident Assistant. Each and every one of those activities left a distinct mark on her, she says, and showed her the importance of getting involved with and contributing to her community. In fact, for Wanda, education, service and giving back are inextricably intertwined.
“If you went to UMBC, giving back comes naturally,” she says. And that dedication to service and giving will now come full circle. Through her planned gift to UMBC, Wanda is ensuring future generations will have the same amazing educational and career opportunities that she did.
Take any modern web page and you will notice that it invariably contains content stitched together from a variety of different sources; it may include the social sharing widgets from Twitter or Facebook or a Youtube video playing widget, it may serve a personalized advertisement from some ad-server or it may include some utility scripts or styles from a third party library hosted over CDN and so on. And if everything is HTML based (as is preferred these days) there is a high probability of collisions between the markup, scripts or styles served from various sources. Generally, namespaces are employed to prevent these collisions which solve the problem to some extent, but they don’t offer Encapsulation.
Encapsulation is one of the pillars on which the Object Oriented Programming paradigm was founded and is normally used to restrict the internal representation of an object from the outside world.
Coming back to our problem, we can surely encapsulate the JavaScript code using closures or using the module pattern but can we do the same for our HTML markup? Imagine that we have to build a UI widget, can we hide the implementation details of our widget from the JavaScript and CSS code that is included on the page, which consumes our widget? Alternatively, can we prevent the consuming code from messing up our widget’s functionality or look and feel?
The only existing solution that creates a boundary between the code you write and code that consumes, is ugly – and operates by using a bulky and restrictive iFrame, which brings with itself another set of problems. So are we forced to adapt to this approach always?
Not anymore! Shadow DOM provides us an elegant way to overlay the normal DOM subtree with a special document fragment that contains another subtree of nodes, which are impregnable to scripts and styles. The interesting part is that it’s not something new! Various browsers have already been using this methodology to implement native widgets like date, sliders, audio, video players, etc.
At the time of this writing, the current version of Chrome (v29) supports inspecting Shadow DOM using Chrome DevTools. Open Devtools and click on the cog button at the bottom right of the screen to open the Settings panel, scroll down a bit and you will see a checkbox for showing Shadow DOM.
Now that we have enabled our browser, lets check out the internals of the default audio player. Just type:
<audio width="300" height="32" src="http://developer.mozilla.org/@api/deki/files/2926/=AudioTest_(1).ogg" autoplay="autoplay" controls="controls">
Your browser does not support the HTML5 Audio.
</audio>
Into your HTML markup. It shows the following native audio player in supported browsers:
Now go ahead and inspect the audio player widget that you just created.
Wow! It shows the internal representation of the audio player, which was otherwise hidden. As we can see, the audio element uses a document fragment to hold the internal contents of the widget and appends that to the container element ( which is known as Shadow Host ).
Shadow DOM subtree or it is the DOM node which contains the Shadow Root.
When rendered, the Shadow tree takes place of Shadow Host’s content.
This process of overlaying the nodes is often referred to as Composition.
Enough chit-chat I say, Let’s get our hands dirty by writing some code. Suppose we have the following markup, which shows a simple welcome message.
<div id="welcomeMessage">Welcome to My World</div>
Add the following JavaScript code or use this Fiddle:
var shadowHost = document.querySelector("#welcomeMessage");
var shadowRoot = shadowHost.webkitCreateShadowRoot();
shadowRoot.textContent = "Hello Shadow DOM World";
Here we create a Shadow Root using the webkitCreateShadowRoot() function, attach it to a Shadow Host and then simply change the content.
Notice the vendor-specific prefix webkit before the function name. This indicates that this functionality is currently supported on some webkit-based browsers only.
If you go ahead and run this example in a supported browser, then you would see “Hello Shadow DOM World” instead of “Welcome to My World” as the Shadow DOM nodes have over-shadowed the normal ones.
Disclaimer: As some of you may notice, we’re mixing the markup with scripts, which is generally not recommended and Shadow DOM is no exception. We have deliberately avoided the use of templates so early in the game in order to avoid any confusion. Otherwise Shadow DOM does provide an elegant solution to this problem and we will get there pretty soon.
If you try and access the content of the rendered tree using JavaScript, like so:
var shadowHost = document.querySelector("#welcomeMessage");
var shadowRoot = shadowHost.webkitCreateShadowRoot();
shadowRoot.textContent = "Hello Shadow DOM World";
console.log(shadowHost.textContent);
// Prints "Welcome to My World" as the shadow DOM nodes are encapsulated and cannot be accessed by JavaScript
You will get the original content “Welcome to My World” and not the content which is actually rendered on the page, as the Shadow DOM tree is encapsulated from any scripts. This also means that the widget that you create using Shadow DOM is safe from any unwanted/conflicting scripts already present in the page.
Similarly, any CSS selector is forbidden to cross the shadow boundary. Check the following code where we have applied red color to the list items, but that style is only applied to the nodes which are part of the parent page, and the list items which are part of Shadow Root are not affected with this style.
<div class="outer">
<div id="welcomeMessage">Welcome to My World</div>
<div class="normalTree">Sample List
<ul>
<li>Item 1</li>
<li>Item 2</li>
</ul>
</div>
</div>
<style>
div.outer li {
color: red;
}
div.outer{
border: solid 1px; padding: 1em;
}
</style>
<script type="text/javascript">
var shadowHost = document.querySelector("#welcomeMessage");
var shadowRoot = shadowHost.webkitCreateShadowRoot();
shadowRoot.innerHTML = ["<div class='shadowChild'>",
"Shadow DOM offers us Encapsulation from",
"<ul>",
"<li>Scripts</li>",
"<li>Styles</li>",
"</ul>",
"</div>"
].join(',').replace(/,/g,"");
</script>
You can see the code in action on Fiddle. This encapsulation applies even if we reverse the direction of traversal. Any styles which are defined inside the Shadow DOM does not affect the parent document and remains scoped to the Shadow Root only. Check this Fiddle for an example, where we apply the blue color to list items in Shadow DOM but the parent document’s list items are unaffected.
There is however one notable exception here; Shadow DOM gives us the flexibility to style the Shadow Host, the DOM node which is holding the Shadow DOM. Ideally it lies outside the Shadow boundary and is not a part of Shadow Root, but using the @host rule, one can specify the styles that can be applied to Shadow Host as we have styled the welcome message in the example below.
<div id="welcomeMessage">Welcome to My World</div>
<script type="text/javascript">
var shadowHost = document.querySelector("#welcomeMessage");
var shadowRoot = shadowHost.webkitCreateShadowRoot();
shadowRoot.innerHTML = ["<style>",
"@host{ ",
"#welcomeMessage{ ",
"font-size: 28px;",
"font-family:cursive;",
"font-weight:bold;",
"}",
"}",
"</style>",
"<content select=''></content>"
].join(',').replace(/,/g,"");
</script>
Check this Fiddle as we style the Shadow Host’s welcome message using the styles defined in Shadow DOM.
As a widget developer, I might want the user of my widget to be able to style certain elements. This is achievable by plugging a hole into the shadow boundary using custom pseudo elements. This is similar to how some browsers create style hooks for the developer to style some internal elements of a native widget. For example, to style the thumb and the track of the native slider you can use the ::-webkit-slider-thumb and ::webkit-slider-runnable-track as follows:
input[type=range]{
-webkit-appearance:none;
}
input[type=range]::-webkit-slider-thumb {
-webkit-appearance:none;
height:12px;
width:12px;
border-radius:6px;
background:yellow;
position:relative;
top:-5px;
}
input[type=range]::-webkit-slider-runnable-track {
background:red;
height:2px;
}
Fork this Fiddle and apply your own styles to it!
If an event that originates from one of the nodes in Shadow DOM crosses the Shadow Boundary then it is re-targeted to refer to the Shadow Host in order to maintain encapsulation. Consider the following code:
<input id="normalText" type="text" value="Normal DOM Text Node" />
<div id="shadowHost"></div>
<input id="shadowText" type="text" value="Shadow DOM Node" />
<script type="text/javascript">
var shadowHost = document.querySelector('#shadowHost');
var shadowRoot = shadowHost.webkitCreateShadowRoot();
var template = document.querySelector('template');
shadowRoot.appendChild(template.content.cloneNode(true));
template.remove();
document.addEventListener('click', function(e) {
console.log(e.target.id + ' clicked!');
});
</script>
It renders two text input elements, one via Normal DOM and another via Shadow DOM and then listens for a click event on the document. Now, when the second text input is clicked, the event is originated from inside Shadow DOM and when it crosses the Shadow Boundary, the event is modified to change the target element to Shadow Host’s <div> element instead of the <input> text input. We have also introduced a new <template> element here; this is conceptually similar to client-side templating solutions like Handlebars and Underscore but is not as evolved and lacks browser support. Having said that, using templates is the ideal way to write Shadow DOM rather than using script tags as has been done so far throughout this article.
We already know that it’s always a good idea to separate actual content from presentation; Shadow DOM should not embed any content, which is to be finally shown to the user. Rather, the content should always be present on the original page and not hidden inside the Shadow DOM template. When the composition occurs, this content should then be projected into appropriate insertion points defined in the Shadow DOM’s template. Let’s rewrite the Hello World example, keeping in mind the above separation – a live example can be found on Fiddle.
<div id="welcomeMessage">Welcome to Shadow DOM World</div>
<script type="text/javascript">
var shadowRoot = document.querySelector("#welcomeMessage").webkitCreateShadowRoot();
var template = document.querySelector("template");
shadowRoot.appendChild(template.content);
template.remove();
</script>
When the page is rendered, the content of the Shadow Host is projected into the place where the <content> element appears. This is a very simplistic example where <content> picks up everything inside the Shadow Host during composition. But it can very well be selective in picking the content from Shadow Host using the select attribute as shown below
<div id="outer">How about some cool demo, eh ?
<div class="cursiveButton">My Awesome Button</div>
</div>
<button>
Fallback Content
</button>
<style>
button{
font-family: cursive;
font-size: 24px;
color: red;
}
</style>
<script type="text/javascript">
var shadowRoot = document.querySelector("#outer").webkitCreateShadowRoot();
var template = document.querySelector("template");
shadowRoot.appendChild(template.content.cloneNode(true));
template.remove();
</script>
Check out the live demo and play with it to better understand the concept of insertion points and projections.
As you may already know, Shadow DOM is a part of the Web Components Spec, which offers other neat features, like:
<myAwesomeNavigation attr1="value1"..></myAwesomeNavigation>. So custom elements essentially give us a way to bundle all the Shadow DOM magic, hiding the internal details and packages everything together.I wont babble much about other aspects of the Web Components Spec in this article but it would do us good to remember that together they enable us to create re-usable UI widgets which are portable across browsers in look and feel and fully encapsulated by all the scripts and styles of the consuming page.
The Web Components Spec is a work in progress and the sample code included which works today may not work on a later release. As an example, earlier texts on this subject use the webkitShadowRoot() method which no longer works; Instead use createWebkitShadowRoot() to create a Shadow Root. So if you want to use this to create some cool demos using Shadow DOM, it’s always best to refer to the spec for details.
Currently, only Chrome and Opera supports it so I would be wary about including any Shadow DOM on my production instance, but with Google coming out with Polymer which is built on top of Web Components and Polyfills coming out to support Shadow DOM natively, this is surely something that every web developer must get his hands dirty with.
You can also stay updated with the latest happenings on Shadow DOM by following this Google+ Channel. Also checkout the Shadow DOM Visualizer tool, which helps you to visualize how Shadow DOM renders in the browser.
]]>
Stroll near The Commons on most weekdays and you’ll see tables piled high with tasty baked goods. The students at these tables are asking for help – spare change, really – to fund their clubs’ latest and greatest pursuits in a way that hasn’t changed much since the university opened in 1966.
But now these passionate student appeals are getting a boost from the power of the people . . . and the internet. UMBC recently unveiled a new crowdfunding website that allows students to harness their personal relationships to bring in support for their own projects on campus. The site – which focuses on university needs as well as student causes – gives students a way to easily use social media to publicize, track and aggregate philanthropic campaigns.
“We are incredibly excited to work with student groups to help them understand the ins and outs of philanthropy through crowdfunding,” says Dayna Carpenter, UMBC’s director of annual giving. “Our students are very motivated to do good in this world, and this is an important element of their education.”
UMBC’s crowdfunding site already boasts colorful channels to help student causes. Visitors can help the SAE Mini Baja team get to their next competition, help the Down and Dirty Dawg Band produce their next CD, or even send students from Engineers Without Borders to Kenya to dig wells.
“Without the help and support of things like our fundraising page, we wouldn’t be able to receive stipends, buy new equipment, pay for instrument repairs, or put out CDs,” says Drew Ballantine, a UMBC senior and member of the Down and Dirty Dawg Band. “These donations allow us to continuously grow by doing more things each year, like adding more performances or playing new music.”
Donors can also support university giving that directly benefits current students, including LGBTQ initiatives on campus or the Stay Black and Gold Fund for those who have emergency financial needs.
“I love the crowdfunding model because it gives us the chance to give back to what we really care about,” says Chris Magaha ’03, information systems management. “And you can see exactly where the money is going to go.”
And that’s exactly why UMBC made the venture into crowdfunding. It gives students a chance to share their projects with the world and get the support they need, while donors can find projects they’re passionate about and see their gifts have an immediate impact.
“The crowdfunding site really is the best of all worlds,” says Dayna. “Even though it’s still new, people have responded very positively. We’re eager to see how this effort continues to grow.”