GET UPDATES BY EMAIL
Enter your email below to get exclusive access to our best articles and tips before everybody else.
I’ve previously written about a way to . This is an easier method that you can use to do the same thing from the GUI interface in either Windows 7, 8, 8.1, or Vista. To recap my earlier article, UAC is ANNOYING.
Note: Disabling UAC will lead to a less secure system, so be warned.
Disable UAC on Windows Vista
Open up Control Panel, and type in “UAC” into the search box. You’ll see a link for “Turn User Account Control (UAC) on or off”:
On the next screen you should uncheck the box for “Use User Account Control (UAC)”, and then click on the OK button.
You’ll need to reboot your computer before the changes take effect, but you should be all done with annoying prompts.
Disable UAC on Windows 7
Windows 7 makes it much easier to deal with UAC settings, and in fact you don’t have to completely disable UAC if you don’t want to. Just type UAC into the start menu or Control Panel search box.
You can simply drag the slider up or down, depending on how often you want to be alerted.
If you drag it all the way down to the bottom, you’ll have disabled it entirely.
Disable UAC on Windows 8 or 8.1
Open up the Start screen, search for UAC, and you should see an option for User Account Control settings. If you don’t, you’ll need to change to search through your Settings first, but then you should see it.
And then you can drag the slider all the way to the bottom, the same as for the other versions of Windows.
Pretty simple.
RELATED ARTICLESWant to allow a standard user account to run an application as administrator without a UAC or password prompt? You...User Account Control is an important security feature in the latest versions of Windows. While we鈥檝e explained how to disable...
Published 11/21/13
GET ARTICLES BY EMAIL
Enter your email address to get our daily newsletter.
Get exclusive articles before everybody else.
Get downloadable ebooks for free!
Get geeky trivia, fun facts, and much more.
Enter Your Email Here to Get Access for Free:
Go check your email!Official jQuery Blog | New Wave Javascript
In case you haven’t heard, Famous Industries () announced today that they are joining the jQuery Foundation as a Founding-level member.
Famo.us joins our other Founding-level members, WordPress and IBM, and our growing list of member companies, who recognize the power and importance of the jQuery Foundation’s open governance for JavaScript technologies.
For those who are not familiar with Famo.us, they offer a free, open source JavaScript platform that enables engineers to build beautiful, cross-platform web apps. It is the only framework that provides an open source 3D layout engine fully integrated with a 3D physics-based animation engine that can render to DOM, Canvas, or WebGL.
Famo.us also provides extensive free training, examples, and tutorials through Famo.us University. Their live coding environment allows students to see their code rendered in real time and work through topics at their own pace. We plan on taking advantage of their passion for education by partnering with Famo.us to deliver a top notch developer event in San Francisco in mid 2015 ().
Today, jQuery continues to be one of the most preferred JavaScript libraries available with 8 out of 10 of the top JavaScript enabled websites and over 60% of the top one million websites* choosing jQuery-enabled libraries. As our community grows and continues to innovate, so do we. This makes the support of our members more critical than ever.
We are working on a number of new initiatives: Making improvements to how our innovative technical community collaborates. Famo.us has a number of widgets they intend to make available as jQuery plugins and we look forward to taking advantage of their support and expertise as we work to improve the extended community guidance around jQuery plugins.
Famo.us developers will be joining our technical efforts so please say ‘hello’ and make them feel welcome. Co-founder and CEO Steve Newcomb has been elected to the jQuery Foundation board of directors. We look forward to benefiting from the unique perspectives, business acumen and life experiences Steve will bring to our board in helping us move forward toward accomplishing our mission.
It’s going to be a great partnership and a busy New Year. With that, please join us and give Famo.us a shout out and welcome them to the jQuery Foundation!
*stats from
Season’s greetings! After a thoughtful review of the Naughty and Nice lists, we have decided to leave a small present under the tree to finish 2014: jQuery 1.11.2 and 2.1.3! These releases include several bug fixes to make your cross-browser development experience better.
The most significant fix in this release is a workaround for a
in Safari 8.0 and 7.1. When this bug popped up we were hopeful that it would be fixed in patch releases but that did not happen. Apple is by far the least transparent browser maker, and we have very little information about when the
might be pulled into Safari. As a result, we have decided to patch this in Sizzle, the selector engine used by jQuery.
A bug like this one emphasizes the benefit of using a library like jQuery rather than going directly to the DOM APIs. Even modern browsers can suffer from bugs that aren’t fixed for a long time, and there are still cross-browser feature differences with several browsers in wide use such as Android 2.3. Special-case code for obscure browser issues can seem unnecessary until you spend a day trying to debug a problem in your own code caused by one. Or worse, lose a paying customer because they couldn’t use your site from their old phone.
Another bug that makes it difficult for us to test jQuery on iOS 8 is that
so the iOS 8 simulator is not recognized by our unit test infrastructure. The
is very simple but Apple won’t tell us if we can count on it being done. For now we’re doing our iOS 8 testing manually.
In addition, this release includes several changes inside jQuery to avoid holding onto DOM elements unnecessarily. Although the old code generally wouldn’t cause things to run incorrectly, web pages might run slowly and use more memory than necessary.
You may notice that we skipped a patch release number in the 2.x branch. We didn’t actually skip it, we built it and found a problem that caused problems when jQuery was used with node. (Many thanks to Denis Sokolov for letting us know immediately and prodding us to fix it!) Rather than shipping those files to the other CDNs, we decided to create new releases.
As far as the potential for compatibility or regression issues, we believe this is a very low-risk upgrade for anyone currently using 1.11.1 or 2.1.1. We are making this release ahead of jQuery 3.0 to ensure that you can use a Safari-safe version of jQuery without the need to review your code for compatibility with changes being anticipated in jQuery 3.0. If you do encounter bugs, in upgrading from the previous version, please .
You can include these files directly from the jQuery CDN if you like, or copy them to your own local server. The 1.x branch includes support for IE 6/7/8 and the 2.x branch does not.
These updates are already available as the current versions on npm and Bower. Information on all the ways to get jQuery is available at . Public CDNs receive their copies today, please give them a few days to post the files and don’t be impatient. If you’re anxious to get a quick start, just use the files on our CDN until they have a chance to update.
Many thanks to all of you who participated in this release by testing, reporting bugs, or submitting patches, including Chris Antaki, Denis Sokolov, Jason Bedard, Julian Aubourg, Liang Peng, Michał Gołębiowski, Oleg Gaidarenko, PashaG, Richard Gibson, Rodrigo Rosenfeld Rosas, Timmy Willison, and TJ VanToll.
Since the last release of jQuery we have moved from a Trac installation to GitHub issues, so there are currently tickets for this release in both bug trackers. References to the Trac tickets have been migrated to GitHub issues, however, so you can use
to review all the tickets.
Thanks for all your support, and see you at jQuery 3.0!
Today, we’re excited to announce that Google has transferred its
to the jQuery Foundation. This polyfill was originally written by Google’s Polymer team but since Google has chosen to put their Pointer Event implementation on hold, we engaged to ensure that the polyfill is maintained and continues to be a tool developers can use as a path to the eventual native implementation in all browsers. Many thanks to Google and the Polymer Team for allowing us to build off their work and continue development.
The jQuery Foundation has been, and continues to be a
and we are specifically
because it will simplify the way web developers handle user interactions. Today developers are saddled with two very different event models for mouse and touch, even though they share many similarities. The result is often code that has a myriad of special cases, particularly when the device itself generates “fake” mouse events from touches. The jQuery Foundation hopes to drive developer adoption of this unified event system. Our goal is to have all browsers implement this standard natively.
Just yesterday, the W3C took the Pointer Events specification to the
stage. This makes Pointer Events one step closer to a finished standard and gives browsers a solid base on which to implement these APIs. Some browsers have even begun their implementation. Unsurprisingly Internet Explorer, where the first implementation of Pointer Events began before being submitted to the W3C for standardization, has implemented Pointer Events and Firefox has a branch of their code base implementing Pointer Events which they . Both of these implementations recently
so implementation is progressing nicely.
We want to thank Microsoft Open Technologies for their . We also want to thank IBM, Mozilla, Google, Dojo and the many other organizations and individuals that have helped and continue to help make developers lives easier through the creation, fostering and promotion of new standards like Pointer Events. If you want to get involved or just want to start using Pointer Events in your projects, head over to the new
and check it out.
We’ve just released QUnit 1.16, an important milestone for the project. This release introduces several new APIs that will become the default in QUnit 2.0. To help migrate to these APIs, you can start using them today in 1.16. Our 2.x upgrade guide provides all the details you need to change your existing test suite to the new APIs.
Here’s a quick overview of the new APIs:
QUnit.test( "assert.async() test", function( assert ) {
var done = assert.async();
var input = $( "#test-input" ).focus();
setTimeout(function() {
assert.equal( document.activeElement, input[0], "Input was focused" );
You still define tests by calling QUnit.test and passing a name and a callback. The callback receives a assert argument that contains all assertion methods. The
method is brand new, replacing the old stop() method. The returned callback, here named done is later called when the test is finished, replacing the old start() method.
In addition, QUnit 1.16 contains several improvements and new features:
: As an enhancement for the async control, test blocks are now Promise aware, meaning QUnit will wait for the test to resolve with the pass or fail statement.
QUnit asynchronous tests can also now be defined using the new var done = assert.async() method instead of the old stop()/start(), making them specific to the test block.
: This method can be used to define tests that aren’t executed, as placeholders or to temporarily disable an existing test (instead of commenting it out). The skipped test is still displayed in the HTML reporter, marked prominently as “SKIPPED”.
testId URL parameter: When clicking the “Rerun” link for a single test, a hash of the test name is now used to reference the test, called testId, instead of the previous testNumber. Using a hash makes sure that the order of tests can change, and QUnit will still rerun the same test you’ve selected before.
: QUnit now also looks for a exports object and uses that to export itself, making QUnit usable on Rhino with the -require option.
There are a few more minor changes. For a full list, .
For future releases, we have several improvements planned as well:
Standardized reporter interface
Currently integration of any unit testing library into other tools like PhantomJS or browserstack-runner or Karma requires custom integration code, a combination of library and tools. We’ve started an effort to create a standard reporter interface that all testing libraries could implement, called , to be consumed by those tools. Coordinating between the various projects and getting them to agree on and implement a common API takes time, but will yield better testing infrastructure for everyone.
Better diff output
When writing unit tests that compare objects with deep structures or many properties, like Ember models or Moment instances, the current diff output is slow and inefficient. There are also comparisons where the diff is hard to read. Replacing the diff library and implementing custom optimizations, like only showing diffs for leafs in big objects, will make QUnit’s HTML reporter even more developer friendly. We have .
Better support for writing custom assertions
Custom assertions are a powerful method of abstraction in test suites. They are currently underused. We want to
for writing custom assertions, along with better documentation of existing and new APIs.
Support for nested modules
Nesting modules, like Jasmine and Mocha support it, gives more flexibility in structuring test suites. There is , but no consensus on the API, yet.
For any breaking changes, we’ll apply the same migration model that we’re currently using. All backwards compatible changes will make it into the next minor release, any incompatible changes will be introduced with a migration layer in a minor release, removing the migration layer in the next major release.
The QUnit Team
The QUnit team also would like to use this opportunity to introduce itself:
At the jQuery Conference in Chicago, September 2014, from left to right: J?rn Zaefferer, Timo “Krinkle” Tijhof, James M. Greene, and Leonardo Balter
It’s hard to believe it’s been nearly eight years since jQuery was released. Web development has changed a lot over the years, and jQuery has changed along with it. Through all of this time, the team has tried to walk the line between maintaining compatibility with code from the past versus supporting the best web development practices of the present.
One of those best practices is semantic versioning, or
for short. In a practical sense, semver gives developers (and build tools) an idea of the risk involved in moving to a new version of software. Version numbers are in the form of MAJOR.MINOR.PATCH with each of the three components being an integer. In semver, if the MAJOR number changes it indicates there are breaking changes in the API and thus developers need to beware.
The concept of versioning gets a little more nuanced with jQuery, where browser compatibility can be just as important as API compatibility. In order to create a slimmer jQuery, the team started shipping two versions in 2013. The first version remained numbered in the 1.x line and, currently at 1.11.1, maintains compatibility with a maximal number of browsers. The second version, starting with 2.0.0 and now at 2.1.1, dropped support for browsers like IE8 or lower in order to streamline the code. Both the 1.x and 2.x versions of jQuery have the same public APIs, even though they differ somewhat in their internal implementations.
Our next releases will use a different nomenclature. As before, there will be two different released files. The successor to what is now version 1.11.1 will become jQuery Compat 3.0. The successor to jQuery 2.1.1 will be jQuery 3.0. There are two different packages on npm and Bower, but they share the same version to indicate they have the same API behavior.
We’ll also be re-aligning our policy for browser support starting with these releases. The main jQuery package remains small and tight by supporting the evergreen browsers (the current and previous versions of a specific browser) that are common at the time of its release. We may support additional browsers in this package based on market share. The jQuery Compat package offers much wider browser support, but at the expense of a larger file size and potentially lower performance.
Despite the big version number jump, we don’t anticipate a lot of migration issues for most current jQuery code. We’re just being good semver citizens with this version bump. Changes such as removing deprecated methods will be detected by a new version of the
to make them easy to find and fix. We’ll have more details on the changes in future blog posts.
So, here’s the TL;DR for version 3.0 of the jQuery API:
If you need support for the widest variety of browsers including IE8, Opera 12, Safari 5, and the like, use the jQuery-Compat 3.0.0 package. We recommend this version for most web sites, since it provides the best compatibility for all website visitors.
If your web site is built only for evergreen leading-edge browsers, or is an HTML-based app contained in a webview (for example PhoneGap or Cordova) where you know which browser engines are in use, go for the jQuery 3.0.0 package.
Until we announce otherwise, both packages will contain the same public APIs in correspondingly-numbered major and minor versions. This should make it easy for developers to switch between the two and be maximally compatible with third-party jQuery plugins.
With each future release, we’ll be making both packages available on npm and bower. Both packages will also be available as single-file builds on the jQuery CDN. Using them from there is as simple as including either jquery-compat-3.0.0.js or jquery-3.0.0.js depending on your needs. We’ve talked with the folks who run Google’s CDN and they will also be supporting both packages.
As we make further progress on version 3.0, we will update everyone with the details about code changes, supported browsers, and the like. Stay tuned!
The jQuery Foundation is pleased to announce that Brandon Aaron has donated his jquery-mousewheel plugin to the jQuery Foundation. Brandon is a jQuery team alumnus and he leaves the plugin in great shape with very few open issues. It’s a , one that’s often used along with jQuery UI and other widgets.
Adopting the mousewheel plugin is part of the jQuery Foundation’s mission to make a web developer’s work easier. We want to ensure that web developers can use this plugin and be confident it will be supported into the future. We can’t do this alone, of course, and encourage the community to pitch in with pull requests and by providing support to the jQuery Foundation. You can find it at .
Abandoned or neglected open source projects can be a thorn in the side of web developers. When a developer’s personal project becomes wildly popular, it often exceeds that person’s ability to maintain and support it. More developers should take the step that Brandon did, seeking out someone who can take over the reins when they no longer have the time. As Eric Raymond says in The Cathedral and the Bazaar, “When you lose interest in a program, your last duty to it is to hand it off to a competent successor.”
During the last two weeks of September, we found our way into the headlines due to a series of attacks on our web servers. Today, we wanted to give everyone a brief update on the status of our websites and a recap of what happened over the last two weeks.
jQuery Under Siege
Early on the morning of September 18th we were hit with a DDoS and went offline. We were down for a couple of hours. The sites were brought back up later that day on September 18th and all seemed well.
Later, during the afternoon of September 18th, we were contacted by a security company named RiskIQ reporting that their crawler had reported malware being served by our content sites. There were never any reports that the jQuery libraries nor the CDN were ever compromised. Immediately upon receiving that report, we completely destroyed and reimaged all of those machines, revoked and reissued all associated SSL certificates, and confirmed that there was no suspicious content being served at that point. Since then, our own team and security folks from Mozilla and MaxCDN have worked to analyze logs and attempt to confirm the impact of this attack.
On September 23rd, RiskIQ went public with their report which picked up steam throughout the day on various media outlets and Twitter. The next morning, September 24th, as DDoS attacks on our properties continued to increase both in frequency and magnitude, , otherwise known as the ShellShock vulnerability, was issued. As we continued to respond to the media discussion and communicate to the community what had happened on September 18th, we were victimized again in a series of much more public attacks involving the repeated defacing of .
Investigations into our systems have yet to find the initial attack vector. However, we did take some steps to make ourselves more secure. For instance, some of our WordPress installs were out of date, all of our servers were vulnerable to the recent shell vulnerabilities, NGINX was slightly out of date as well as maybe a few other patches etc. that needed to be made. The infrastructure team dove in and began making those changes and started building new, fully patched and secured servers to host our sites. It appears these changes were effective as the defacing stopped and we have not seen any evidence of intrusion since.
Later on September 24th, a massive and unrelenting DDoS attack began. It seemed as though it would come in waves, but did not stop until late on September 28th. Most of the time on September 26th and 27th was spent trying to implement various products and solutions in order to keep the servers alive. We fought day and night to try to keep the sites up. We have to commend Corey Frang, Adam Ulvi, the rest of the infrastructure team, they worked through the nights and in alternating shifts to try to keep us on the internet. Without their efforts, we would not have had the short amounts of uptime we did. One significantly important step that we took was to reach out to , who generously and rapidly gave us access to their Enterprise service which has helped tremendously in mitigating these attacks.
Moving Forward
jQuery and the jQuery Foundation are important to the web ecosystem, as is evident from the amount of press and the number of concerned individuals and organizations that have reached out to ask questions about this attack. The jQuery Foundation works on a daily basis to maintain and improve our projects and the infrastructure around those projects. The goal of this work is to continue to make web developers’ jobs easier and make sure they have a voice in the world of standards and browsers. However, these objectives take a large quantity of resources. Whether those resources are provided by access to expertise of a company’s employees or services, or through financial support, we would be unable to continue this important work without the support of the open source community and our supporting members.
We have been asked several times throughout this ordeal about why we didn’t have XYZ service in place or why we didn’t have our security team keeping a closer eye on these types of risks. The simple answer is that our budgets are tight and resources are limited. Our infrastructure team, and most of our teams for that matter, are made up of volunteers who give their time for free to make sure things keep running. The
and ShellShock vulnerabilities are recent examples of how badly things can go when open source projects are taken for granted and just assumed to be OK. Eventually something is going to fall through the cracks and those cracks become larger and more frequent when people are doing what they can in their spare time.
So how can you help? As an individual, get involved in one of our projects. We can always use help writing code, designing, maintaining servers, working on events and the list goes on. Take a look at
or come say hi on IRC in one of our many channels listed on . As an organization, we would love to hear about any service you may be willing to donate, any developers or other skilled professionals that you could spare for a few hours a week or if you can help financially. Send us a message at
and let us know how you can help.
We haven’t wanted to say too much about these attacks as they have been happening because we remain a juicy target in the eyes of hackers who are continuing to attempt to infiltrate our servers even as of this writing. In sharing all of this information with the community now, we’ve tried to balance the need to explain what’s been happening with the potential backlash that could happen as a result of coming out publicly and saying that we believe we have the situation under control.
That said, we do at this point believe that we have the situation under control. For this, a huge thanks is due to the entire jQuery infrastructure team, who rolled up their sleeves and worked tirelessly on these issues to get us back to a good place. We will continue to be vigilant in ensuring the reliability and safety of all of our resources for our community of users.
Today at 11:15AM EDT, the jQuery Infrastructure team received widespread reports and confirmed a compromise . This attack was aimed at defacing our sites, and did not inject malware like the attack that was reported on September 18th by RiskIQ. We believe that these are separate incidents that may have used the same attack vector.
We took the site down as soon as we realized there was a compromise and cleaned the infected files. We are taking steps to re-secure our servers, upgrade dependencies, and address vulnerabilities.
At no point today have there been reports of malware being distributed from any of our sites, nor has the code of any jQuery libraries on our website or CDN been affected or modified today or during last week’s reported attack. Some of this confusion stems from last week’s attackers having set up a domain name intended to dupe users into thinking it was the official jQuery CDN. Please note that the official domain for jQuery files hosted from our official CDN is .
There has also been
of developers and administrators who
and the rest of our WordPress sites have somehow been compromised by this attack. However, the only people who have a user account for the WordPress sites affected by these attacks are members of the jQ we do not have any public user registration for any sort of account on any of the affected sites.
We are continuing to actively work on and monitor this situation and will update you as we learn more.
We have moved
to a new server only running code we trust and are continuing to monitor the situation closely. – September 24, 2014 at 5:07 PM EDT via
Lastest update on the compromise:
Earlier today, RiskIQ published a
stating that
web servers were compromised and serving the RIG exploit kit for a short period of time on the afternoon of September 18th. Our internal investigation into our servers and logs have not yet found the RIG exploit kit or evidence that there was in fact a compromise.
RiskIQ was able to make contact with the jQuery Infrastructure team on September 18th, at which point with members of the RiskIQ team tried to find evidence of compromise.
So far the investigation has been unable to reproduce or confirm that our servers were compromised.
We have not been notified by any other security firm or users
confirming a compromise. Normally, when we have issues with jQuery infrastructure, we hear reports within minutes on Twitter, via IRC, etc.
At no time have the hosted jQuery libraries been compromised.
Currently the only potential system compromised is the web software or server that . We have asked RiskIQ to help us look through our server logs and systems to help identify when and how a compromise happened.
Please check this blog post for updates on the situation.
Even though we don’t have immediate evidence of compromise, we have taken the proper precautions to ensure our servers are secure and clean.
If you happened to visit any of the our sites on September 18th and are afraid of your system being compromised you can follow the advice RiskIQ recommends:
Immediately re-image system
Reset passwords for user accounts that have been used on the system
See if any suspicious activity has originated from the offending system
With just over a month until we set forth for the Windy City for the first jQuery Conference in Chicago, the moment’s opportune to bring you up to speed on what we’ve got in store for you this September!
Whatchu Talkin’ Bout?
Our speakers and talks are the highlight of any jQ our lineup in Chicago is no exception. We aim to cover a broad selection of subjects from across the realm of web development, from our jQuery Foundation projects like jQuery, jQuery UI, and jQuery Mobile (so we’ll be having talks from project leads Dave Methvin, Scott González, and Alex Schmitz) to the new frontiers where JavaScript now treads (so we’ve got Lisa Deluca talking about using Arduino and Cordova together, and Micah Ransdell talking about Netflix’s adoption of Node.js). We know you want to know more about the future of the open web platform, and that’s why we’re happy to have folks like John K. Paul to go over coming changes to the language in ECMAScript 6, and TJ VanToll and Kevin Hakanson to discuss new browser APIs for form validation and cryptography.
A lot of you come to conferences to learn practical things you can take home with you, and that’s why we’re excited about sessions from (among others) Brian Arnold and Cory Gackenheimer on debugging techniques and Phil Dutson on the process of building a jQuery plugin.
We know, however, that there’s a lot more to releasing code than, well, writing code, and we’re happy to have Kassandra Perch, Alex Sexton, and Kelly Andrews joining us to talk about how to choose and use tools to ship and support the projects we work on. And we know some of you travel to conferences for the fun and games, and we’re thrilled to have Sara Gorecki and Bodil Stokke on hand to talk about building games with web technology.
This is just a handful of the speakers and subjects that’ll be on our Chicago stage(s), and we invite you to take a few minutes to
to see what else is on the docket!
Can You Hack It At #jqcon?
Of course you can! In Chicago, however, we’re partnering with MaxCDN, DigitalOcean, and MediaTemple to officially encourage you to do so! We’ve got a wealth of data about how folks use the jQuery CDN at , and it’s up to you to help us understand it. The hackathon starts the night before the conference on September 11th, and you’re free to use any medium you see fit to play with the data, whether it’s a web application or a robot. Our sponsors have stepped up to reward three participants with , so we hope you join us to team up, explore, and build!
Coming Home to Roost
We’re partnering with
for the second time this year to extend our trip to Chicago with Roost, a two-day intensive class on building modern web applications taught by Ashley Williams, Ben Alman, Irene Ros, and Mike Pennisi. Roost is targeted at developers who already know JavaScript, jQuery, HTML, and CSS, and are looking to understand how to develop a better workflow for building, testing, and maintaining their applications and incorporate technologies like Backbone, RequireJS, Stylus, and more. You can check out
to find out exactly what’s planned.
Accommodations
Both jQuery Conference and Roost are taking place at the
in the heart of the city, so the hotel’s a convenient place to stay for the purposes of both your edification and your vacation. We’re only able to offer a discounted rate of $269 per night until August 15th, so make sure to make your
as soon as you can! Staying in our room block is a really helpful way you can help the jQuery Foundation fulfill some of the large financial commitment we’ve made by setting up shop in Chicago.
Brought To You By
Our sponsors and foundation members make a huge difference in our ability to host an awesome jQuery Conference for the community, and we’re happy to take a moment to thank them right here! So here’s a big THANKS to Diamond sponsors
and , Platinum sponsor , Gold sponsors , , ,
& , and Silver sponsors
& . (We’re still welcoming sponsors – if you’d like to have your company be a part of #jqcon, please !)
Student Discount
We’re glad to be able to offer a discount to current students interested in attending jQuery Conference or Roost. Please
with us for more information on how you can save $150 on tickets to one event, or $200 on a combination ticket. We know the discount is modest, but this is only the second time we’ve been able to offer a student discount of any kind, and we hope it helps. Please be advised that if you use this discount, you’ll need to show a valid student ID at registration.
The summer’s been flying by and we can’t believe we’re only five weeks out, and we hope you’ll consider joining us on our trip (or that you’ve already booked your ticket!). Check out
for more on our program and speakers, lodging, and to . If you have any questions, always feel free to get in touch with us on}