    
|
Towson University’s new Tiger Arena opens tonight. The arena cost $70 million, funded through $20 million in Towson’s reserve funds, combined with bonds paid back through a student fee set aside for construction projects. UMBC economics professor Dennis Coates told the Baltimore Sun that although new arenas generally succeed in increasing the owner’s ability to generate revenue, whether that benefits those who pay for construction is less clear. “It creates a nice buzz,” said Coates, “but otherwise, the impact is spread out.”
Coates also commented in a recent Wall Street Journal article on how Brooklyn’s Barclays Center impacts local retailers, particularly food vendors.
]]>|
|
Programming is not exactly like riding a bike. You can’t take a year off and hope to pick up right where you left off. Not only do the languages themselves evolve every few months, but so do best practices. Experienced programmers can get stale very fast if they don’t keep abreast with the latest trends, and novice programmers can really stunt their growth if they’re only learning off and on.
As a co-founder of a new startup, for me the first few months involved a lot of product work (design and development). I was constantly learning new techniques while I built our first version. But as anyone in the startup world knows, your job changes from day-to-day. Since we launched around a month ago, I’ve spent less time coding and more time doing sales, marketing, and business development. Since programming is simply a means of building a product, at some point you need to shift your attention to selling what you’ve built.
It’s a blessing and a curse that I’ve been taken away from a day-in and day-out programming schedule. Part of me was happy that I’d programmed the product to a point where I felt comfortable being able to sell it, and part of me knew that my momentum in learning to program would be slowed. Coming back and doing the front-end of a Customer Story reminded just how detrimental taking four weeks off from programming can be. Something that I would have knocked out in no time when I was in the flow only a month ago took me much longer because I was rusty.
Not only was I rusty writing code, but also my mental focus was now on the business side of the company and not with the same precision on the product. If you want to get really good at programming something, it’s best done consistently for a lifetime. I don’t have that luxury, so I’ve been trying to come up with alternative ways of staying fresh.
I’ve come up with three ideas to keep me moving forward:
Please leave a comment if you have other ideas for staying fresh.
The post Staying Fresh appeared first on Treehouse Blog.
]]>|
|
|
|
This set of 25 Colorful Grunge Textures was designed by Florin Gorgan and is perfect for use as overlay textures on your photos. You can see more of Florin’s work in his site or his Etsy shop.
For best results, set the texture layer to Soft Light, Overlay, Multiply or Screen, depending on the look you want to get. You might also want mask some parts of the texture where you don’t want it to take effect. You can also use these textures as backgrounds for your design work, or to add a unique texture to your design or typography.
The pack contains 25 .jpg textures at 5000 by 5000px saved at 300ppi. The textures are compatible with all photo editors that support layers (Photoshop, Photoshop Elements, GIMP, Pixelmator etc.), both PC and Mac.
These textures are for both personal and commercial use. See the full preview after the jump… Enjoy!
Please enter your email address below and click the download button. The download link will be sent to you by email, or if you have already subscribed, the download will begin immediately.
| 10 Professional Facebook Page Templates – only $17! |  |
|
|
|
|
Have you ever meet a brash punk kid that annoys you to no end but he's so damn talented that you can't help but want to work with him? That's how I felt when I first met David Walsh several years ago. Since then, I've seen him mature into a respected and often quoted software developer and most recently, a new dad. He hasn't lost his snark and feistiness and he continues to hone his skills daily, often sharing his best tips on his awesome namesake blog.
It's time to get a little more info on what makes David tick and I had the opportunity to hit him with some tough questions.
My blog's domain was originally "bludice.com", but I decided to brand the blog after myself since BluDice doesn't mean anything and it certainly wouldn't help me in my career path. All of the relevant .com's were taken and since I wanted to brand my blog after myself, .name just seemed to fit. In hindsight, I should have tried harder to find a .com. I bought "david-walsh.com" a few years ago, so maybe I'll migrate to that some day.
I'm not involved in the project anywhere near as much as I used to be and not as much as I would like to be. Job circumstances (working at SitePen for two years, which is a Dojo shop) took my attention away from MooTools. I'm still in the MooTools development IRC channel each day and still keep up with where the next version of MooTools is at, so I'm involved enough to know what's going on at all times. I also hope to make it to the next MooTools Hackathon in London.
MooTools was created to provide a modular, compact, Class-based JavaScript utility, which was different than jQuery's goal at the time. jQuery's popularity didn't affect the MooTools roadmap at all. MooTools' goals and mission never changed beyond what we set for ourselves. Developers believe there is a competition or hatred between the JavaScript frameworks, and it simply doesn't exist, nor did it ever.
Creating crap code is possible with any framework…
I can't answer this for the MooTools team, so my answer strictly represents my own thoughts. The tension between jQuery and MooTools was built up by members of the community, not necessarily the team members themselves. Maybe there was more on the jQuery side, but I know that we didn't give jQuery much thought.
The main issue that jQuery has fought, from the perspective of other JavaScript framework users (not just MooTools), is that the low barrier of entry enables "n00b" developers to create a lot of unoptimized, crap code. Creating crap code is possible with any framework, but the other frameworks required more JavaScript knowledge and thus were more able to avoid this problem, to a degree.
I also get the feeling that other framework users get hung up on jQuery's popularity and seeing it as an inferior toolkit; i.e. the "McDonald's" analogy that they're super popular but that doesn't make them good. Unfortunately in my experience in having worked within a whole bunch of different JS toolkit communities, jQuery seems to get the brunt of negative comments.
I've been long accused of being a "jQuery hater", and while I'll admit that jQuery isn't my cup of tea and I don't choose to use it on my personal projects, I far from hate jQuery. It's a tool, like any other, it has been hugely helpful to millions of developers around the world, and that's something you must respect.
Aside from the locker room ribbing that I'm sure comes with being a part of any group, no one said anything, and why should they? In reality, creating mirroring tutorials and demos with both jQuery and MooTools helped to bridge the perceived code gap between the two frameworks, and hopefully got users of each framework to try the other. I learned a lot from the experience and hopefully others did too!
There are a number of challenges that come with being an active member of an open source community. Organization is incredibly difficult because you must deal with language barriers, cultural differences, time zone differences, and interesting personalities. You also need to keep in mind that OSS work usually isn't a developer's primary job (thus they aren't getting paid for the OSS work) and that they also have a family to spend time with. And of course, most OSS devs just want to develop and not promote or formally release work in a timely manner.
To succeed in open source communities, it's important to be understanding, patient, and willing to work with different types of people. Everyone has a good heart, and everyone wants to succeed, but each brilliant dev has their own route of getting there. Once you learn to manage your contributors, your project will succeed and more contributors and users will flock to you!
In a perfect world, JavaScript framework users would use the modules they needed and would avoid massive load.
They should be complimentary, yes, but there are a few problems that we've seen since the explosion of framework usage. The first problem is that developers will include an entire framework (animates, AJAX, etc.) just to solve one problem, and thus bloat their website tremendously when a microframework or a few lines of pure JavaScript should do the trick. Another problem is that relying on frameworks and their abstractions prevent the developer from truly increasing their JavaScript skills.
In a perfect world, JavaScript framework users would use the modules they needed and would avoid massive load; unfortunately that isn't a common enough practice today. More and more developers are adopting this practice though, so I'm hoping this won't be such a debate in the future.
They'll have to become more specialized and evolve or they'll find themselves irrelevant. Of course, we all know how long it takes for browsers to implement these types of new features, so we're assuming the same JavaScript frameworks will be there at that time. The main thing we can count on, however, is that evolving is the only way for any project to survive.
Some JavaScript frameworks are heavy into promotion and some aren't. Dojo developers definitely aren't. Dojo also had a stigma of not having good documentation, which may have turned people away. I would also argue that Dojo's always been more focused on building feature-rich "web apps" rather than basic websites. Dojo's documentation has gotten much better and they continue to push the client side boundaries more than most JS toolkits, so I would really encourage developers to give Dojo a shot!
Being a remote developer doesn't play as large of a role as most would think.
Going from creating private, internal web applications to working on an important website that gets millions of views each month forces you to reevaluate your development process. The MDN (Mozilla Developer Network) team has adopted a frequent release cycle, pushing code updates many times a day. Spot checking and unit tests become increasingly important as we add features. Localization plays a massive part in MDN development too. Each piece of code requires a lot of thought, so we do code reviews before merging any changes.
Being a remote developer doesn't play as large of a role as most would think. Our QA engineers and IT team are always there to lend a hand. Mozilla has made remote development a breeze.
Mozilla does well in recruitment so I work with dozens of brilliant, dedicated, and responsive developers. Most communication is done via IRC and Bugzilla tickets, and we're never shy about jumping on Vidyo or Skype to get some face-to-face time. Remote employees have weekly 1:1 meetings with managers to ensure everything is going smoothly. Most teams have a bi-monthly meeting where the team can discuss what progress has been made and what goals should be tackled next. Mozilla provides the perfect balance of freedom and structure, which is the main reason I'm so happy to be a Mozillian.
Mozilla's support of open source and going the extra mile to improve the web have changed my thoughts on OSS development immensely. My colleagues are an inspiration and that energy is infectious. Most of my colleagues have popular open source projects and are happy to jump in and help when needed. A majority of Mozilla websites and back-end apps are hosted on GitHub, even sites like the Firefox Marketplace and Mozilla Developer Network, so basically everything is available to the community. When I got to Mozilla, I was surprised at how many contributors there were to the Mozilla family of websites. I loved the Open Source community and my experience has taken that love to the next level; I cannot imagine working on proprietary programming ever again.
Having a child puts life in perspective. Most nights over the past five years I would get done with work and then spend the rest of the night on my computer writing blog posts. I got a lot out of doing that, but I would frequently get burnt out. With Jack around, I'm happy to not spend so much free time on the computer, and instead opt to take him on walks, take him to visit his grandparents, and generally just get out of the house. Seeing your kid smile makes you realize there's more out there than loop optimization and dealing with negative tweets.
Working from home is sweet; I get to save money on gas and food, take a walk when I get frustrated, avoid distractions from coworkers, set my own work schedule, etc. The biggest drawback is working too much, which is something I've been guilty of for years now. Just like moderating anything else, however, you need to get into a routine and cut yourself off at a given time. You should also cut yourself off when you feel the icy glare of your spouse… :)
Let’s be honest, we have a pretty good gig.
If he has interest in development as he grows up, I certainly won't push him away from that career path. Let’s be honest, we have a pretty good gig. We can (sometimes) work from home, make good pay/benefits, travel around the world, make extra money consulting from home, and generally won't have a problem finding a job. Tech jobs come with all of those benefits.
Of course programming comes with its drawbacks. There's a lot of negativity in the JS community, remote collaboration can be a nightmare in some situations, and clients oftentimes don't understand the work that goes into creating a solid site/app, so justifying price becomes difficult.
In the end, if it's what he wants, I'm happy to help him along the way.
My advice is two-fold. First, choose sponsors which are good matches for the main topics of your blog. Second, don't overdo ad placement, remember that ease of consumption is still the most important thing. Writers should also avoid animated GIF ads, text link ads, and auto-playing videos. As your site continues to be usable and you put up content regularly, the income will arrive.
I get incredibly annoyed with people who assert that a blog shouldn't have advertisements and for so many reasons that I could go on for hours, but a few brief points are:
Picking a campaign is usually the easy part. You accept adverts from businesses you've used, believe in, and are reputable. Stick to those rules and you're bound to do OK.
In the end I don't understand people who feel the need to comment on how others make a living; it's petty, rude, and again, embarrassing.
I created a forum section for a few reasons. The first reason is that since the official MooTools-hosted forums were taken down, and the "unofficial hosted forums" were taken down, there's been no central place for MooTools users to get support. I also want to establish a more community feel to my site. Lastly, I get probably a dozen emails per day asking for help with a jQuery snippet, PHP problem, or follow up to a specific blog post. I'd much prefer those questions be posted to the forums so that (1) another user can help out if I can't and (2) I can avoid receiving and sending the same emails. It seems like a win-win all around.
Thank you David, for participating in this interview. We really appreciate it.
To connect with and learn more about David, be sure to check out his website.
]]>|
|