The UMBC Graduate Cybersecurity Program is offering the following courses over the Summer 2014 session.

Each class will meet one or two days a week in the late afternoon or evening, depending on the length of the session where the course is offered.

• CYBR 620: Introduction to Cybersecurity (Parr)
  T/TH 6-8:45PM
  Summer I (6 weeks) May 27th-July 3rd, 2014
• CYBR 691:  Special Topics in Cybersecurity: “Software Security” (Coman)
  M/W 7:10-9:40PM
  Summer I (6 weeks) May 27th-July 3rd, 2014
  Pre-Req: CYBR 620 or equivalent

Offered to students enrolled at the Universities at Shady Grove campus ONLY

• CYBR 691: Special Topics in Cybersecurity: “Cybersecurity Risk Management” (Shariati)
  M/W 7:10-9:40PM
  Summer I (6 weeks) May 27th-July 3rd, 2014
  PreReq: CYBR 620 and enrollment at the Universities at Shady Grove

The deadline to apply for Fall 2014 admission to the UMBC Graduate Cybersecurity Program is August 1, 2014.

Highly successful teams have members who exhibit certain key characteristics, most notably trust in others and a sense of commitment to the team. In the early stages of team development, leaders must set up structures and processes that support the development of these team characteristics. This one-hour course offers strategies used to build trust based on encouraging honest, accountable, fair, and positive behavior. The course also provides leaders with strategies that help increase team member commitment, such as being supportive, making members feel secure, providing interesting work, and acknowledging contributions and achievements. By using these strategies, team leaders can develop a cohesive team that works together to reach its goals.

This is course number:  team_03_a04_bs_enus

Visit the UMBC SkillSoft website for a Quick Start Guide, FAQs, and the link to log in to SkillPort.

For more information about the Business Exploration Series courseware, click here.

To schedule a department presentation about using SkillSoft for professional development, call ext. 5-6262 or hrtraining@umbc.edu.

Libraries have long been a bastion of scholarly pursuits and studied silence, but the UMBC Chapter of Young Alumni (CYA) is about to change all that when it hosts the 9th Annual Wine Tasting and Silent Auction at the George Peabody Library on April 25. So go ahead, break  out the swanky suits and classy cocktail dresses for a trip to the library that is anything but average!

Now in its 9th year, the wine tasting and silent auction is a much-anticipated annual event for all of UMBC’s alumni. The event promises a wide array of delicious wine and food pairings that will delight the taste buds, and a silent auction that will tempt even the most frugal of folks.

The event, which travels to a new venue each year, also offers a unique chance to explore hot spots in Baltimore. Located in picturesque Mt. Vernon, this year’s venue, the George Peabody Library, will be a studied backdrop to an evening filled with jazz, excellent company, refined refreshments and fine wine.

“The venue locations are always unique, and CYA does a fantastic job bringing in high-quality donations for the auction,” says alumnus Nate Dissmeyer ’07, has been attending the event for several years.

For all the delights the event has to offer, it also boasts an important mission: Your attendance and participation in the silent auction will benefit the Alumni Association Scholarship for current UMBC students.

Through these scholarships, the Alumni Association strives to make a meaningful difference in the lives of deserving students to help them achieve their dream of receiving a degree from UMBC and join the many thousands of others as UMBC alumni.

So join us on Friday, April 25, as we enjoy an evening of food, drink and good company, all with a great cause in mind. Tickets are on sale now for $35 per person.

Get your tickets to the wine tasting today!

A huge thank you to the sponsors of this event:

True Grit Sponsors: UMBC Training Centers, White Cliffs Consulting, Bacchus Importers LTD, The Classic Catering People, Deutsche Bank Securities, Inc.
Black & Gold Sponsors: Lebherz Oil & Vinegar Emporium, LLC; VPC, Inc.; Cyberpoint; ATS
Retriever Sponsors: Kara Freeman ’91, The Pittman Family, the Jeffrey Group at Morgan Stanley Smith Barney

Do you think Obamacare is good for America? Or do you prefer to the Affordable Care Act?

Yes, you caught it. They’re the same thing.

 But not everyone makes that connection. When many Americans cannot name their own Vice President’s name it is not surprising to hear a 2013 Gallup poll found  45% of Americans approved of the “Affordable Care Act,” whereas only 38% approved of “Obamacare.” 

So what’s in a name?

“The Patient Protection and Affordable Care Act,” or Affordable Care Act for short, is the name that the President himself generally uses for the law. Others prefer the (admittedly catchier) term “Obamacare.”  

Opponants of the act used this title pejoratively early on in the 2012 campaign in an effort to tie Obama’s election fate to the controversial health care initiate. Obama later started to embrace the term himself.

Online news source The Wire credited the first recorded usage of the term to none other than Mitt Romney. He used the word in May of 2007, along with the similar phrase “Hillary-Care.”  However it originated, the title “Obamacare” seems here to stay.

What do you think the history books will say about this policy?  And what will they call it? 

There’s more to writing good front-end code than knowing every HTML tag, CSS selector, or the latest front-end features and techniques. And as I mentioned in a recent blog post, writing good code takes a lot of patience and practice. But how do you know if you’re writing good code, especially if you’re just learning how to code?

Using real-world examples found on several websites, let’s take a look at common “red flags” to look for when writing code and evaluating its quality.

Complex, Overqualified Selectors

Look out for complex CSS selectors. For example:

.wrapper .main .post a {...}

These are one of the most “expensive” selectors in CSS, because browsers have to parse a lot extra of elements and selectors. Try to make your selectors as lean as possible:

.post a {...}

Instead of having an overly specific selector, it’s usually best to create a class for a particular element:

.continue {...}

Qualifiers in selectors should also be avoided, as they are not reusable, too specific, and create more work for the browser. The nav and p qualifiers in the following selectors are an example of this:

nav.social {
      float: left;
    }
    p.intro {
     font-weight: bold;
    }

What if at some point you need to use the .social class in a ul or the .intro class in a span? Avoid having to dig through your CSS to fix what you should have done correctly from the get-go, or worse, rewriting the rules unnecessarily.

Relying on Parent Selectors

A parent selector lowers the specificity of a child element. Sometimes you can’t avoid them (with anchor elements, for example), but if you have selectors like the following:

.sidebar {
      ...
    }
    .sidebar .title {
      ...
    }

a better approach is using a namespace as a modifier.

.sidebar {
      ...
    }
      .sidebar-title {
        ...
      }

This keeps sidebar-title self-contained and modular — it doesn’t rely on the parent selector and can be used anywhere.

Repeating CSS

Avoid repeating the same chunks of code. Look for property/value pairs that are repeated multiple times throughout the stylesheet, then logically group them so that there’s only one occurrence of that block of code.

.label {
      display: inline-block;
    }
    .button {
      display: inline-block;
      border-radius: 10px;
    }
    .field {
      display: inline-block;
      border-radius: 10px;    
      padding: 5px;
    }

Always think “DRY”(Don’t Repeat Yourself):

.label,
    .button,
    .field {
      display: inline-block;
    }
    .button,
    .field {
      border-radius: 10px;
    }
    .field {  
      padding: 5px;
    }

Resetting and Forcing CSS Values

Keep an eye out for rules where you are rewriting CSS properties or setting them back to their initial values. For example:

h2 { 
      font-size: 1.2em;
      font-weight: 700;
      padding-bottom: .5em;
      border-bottom: 1px solid; 
    }

h2 styles are then reset further down in another rule:

.post h2 { 
      font-weight: 500;
      padding-bottom: 0;
      border-bottom: none;
    }

When adding new components, you shouldn’t need to recode or undo patterns and problems you’ve already solved with existing CSS. Instead, a better solution would be to create the following rules:

h2 {
      font-size: 1.2em;
    }
    ...
    .secondary-headline { 
      font-weight: 700;
      padding-bottom: .5em;
      border-bottom: 1px solid; 
    }
    .post-title { 
      font-weight: 500;
    }

Also, !important declarations should never be used to force a CSS value –– avoid using them unless absolutely necessary.

.last {
      border: none !important;
    }

!important breaks the natural order of the cascade and, when abused, can lead to maintenance and specificity nightmares. There are few use cases for !important, for example: temporarily testing or debugging CSS issues, overriding certain inline styles when you have no control over the HTML, and aiding accessibility –– just be careful with it.

Excessive Markup

Look for unnecessary use of HTML tags being used for layout:

<p><h4>UX - User Experience Design</h4></p>

There’s no need to wrap the block-level h4 in a p. If you’re using the <p> to give the <h4> extra margins or padding, that needs to be solved in the CSS instead.

IDs Instead of Classes

Avoid using an ID wherever you can use a class. IDs are heavy on specificity and cannot be reused. The nav ID shown below can only be used once in a page.

<ul id="nav">
      ...
    </ul>

What if you need to add a nav component? Use classes instead:

<ul class="main-nav  nav">
      ...
    </ul>
    ...
    <ul class="footer-nav  nav">
      ...
    </ul>

.nav a {
      display: block;
      color: white;
      padding: 5px;
    }
    .main-nav a {
      border-bottom: 1px solid;
      font-size: 1.1em;
    }
    .footer-nav a {
      border-bottom: 1px dotted grey  
      font-size: .85em;
    }

It’s best to use IDs as JavaScript hooks or as fragment identifiers in a page. Certainly avoid using one ID for styling, JavaScript, and as a fragment identifier. Doing so will make your architecture fragile because you’re setting up dependencies among CSS, JavaScript, and the fragment identifier.

Closing Thoughts

Front-end code that is poorly thought-out can be a strain on maintenance and development in the long run. When writing code, your goal should be making sure that it’s reusable, maintainable, and scalable. Your CSS should also be predictable, so if you need to update or add new components, they shouldn’t affect other parts of your site.

Keep in mind that at some point your site or application will need to scale, which might require more developers working on and maintaining the code. That’s why it’s important to write code that can be easily managed by designers and developers who are looking at our code for the first time.

The post How to Evaluate Front-End Code for Inefficiencies appeared first on Treehouse Blog.

The Cascading Style Sheets (CSS) Working Group has published two Working Drafts today:

• CSS Line Grid Module Level 1. This module contains CSS features for aligning content to a baseline grid.
• CSS Scoping Module Level 1. This specification defines various scoping/encapsulation mechanisms for CSS, including scoped styles and the @scope rule, Shadow DOM selectors, and page/region-based styling.

CSS is a language for describing the rendering of structured documents (such as HTML and XML) on screen, on paper, in speech, etc. Learn more about the Style Activity.

The Web and Mobile Interest Group has published a Group Note of Review of apps that use network information. The web platform currently lacks a means of exposing network-related information to web applications. Network information includes, but is not limited to, the type of network connection currently in use by a device (e.g., cellular, Wi-Fi, etc.). It can also include information such as the system notifying the application when the type of connection changes from one type to another (e.g., from cellular to Wi-Fi). Learn more about the Mobile Web Initiative Activity.