1.) Math is More Important Than You Think
Math is all over Computer Science in many different ways. Software Engineers will use discrete math when working out algorithm complexity and efficiency, in graph theory, and recursion. People who work more directly with hardware will use discrete math in designing logical circuits and use automata theory for making finite state machines. At that level you are also working with the large amount of math inherent with electrical engineering. In research aspects you will be using probability and statistics for performance measurements and comparisons. Even game programmers use a lot of math when creating 3D environments.
2.) You'll Need To Write More Than Just Code
At the base level you will be writing comments in your code. Those are there for others to comprehend what you are trying to do, so explain what you are doing well. In software engineering you may be writing requirements, specifications, test plans, and more. There may be a time later in your CS career where you may need to write a research paper, that may get peer reviewed. Good writing skills will help you. Pay attention in your business writing classes and learn good technical writing skills now.
3) Don't Procrastinate
We know you've heard it a million times, but this is the worst possible thing you can do in a programming class. When you get an assignment, look it over and start on it right away. In the likely chance that you can't work through an error or figure out the logic, you'll have time to contact your instructor or use other available resources to solve the problem.
4) Don't Overcomplicate Things
The smaller a block of code is, without being redundant of other code, the better. When you break down algorithms which have nothing in common, often there is a loop or operation which is not unique, other than the parameters involved. A single method/function should not be longer, or wider than a standard 800x600 monitor view. If you comment well, a little larger is acceptable.
6) Impress Your Instructors, But Not Too Much
Your instructor can be your best friend, but don't be a suck up. Ask questions and show your instructor you're interested but don't annoy the rest of the class with constant questions and meaningless comments. If you can get to know your instructor, you may be able to leverage that relationship in the future for internships and recommendations.
7) Flowcharting Early and Often
Any good programmer will tell you planning is the most important part of any project. You'll have to flowchart when you get a real job, so get good at it now. Planning a project out before you start, even if it's just good pseudocode, can save you hours of frustration. Don't start your project in the compiler, instead sit down with a piece of paper and plan out your program.
8) Make Sure This is What You Want to Do
Many computer science students get into CS because they like games. Now there are a lot of positions in Computer Game Design that do not require you to be a programmer, so if you are not interested in the coding aspect talk to someone who might direct you to a better path. Areas such as Technical writing, Dramatic Writing, graphic arts, business management, and many more might be better places to go. Use your minor/electives to take computer oriented classes and get to know the CS majors.
9) Use All Your Resources
Don't hit a road block and then panic. There are thousands of resources online to help you work through a problem. From tutorials, to forums (like http://www.dreamincode.net), to live help, you should be able to find the help you need. Just remember it can take more than a few minutes for someone to help solve your problem so don't wait till the last minute. Google is definitley your friend and don't feel embarassed if you have to search for your problem. Don't expect people to do the work for you though, you'll still have to put forth some effort.
10) Become a Well Rounded Programmer
Programming is more than just C++ or Java. If you plan on programming for a living, you'll need to learn the business side of programming. This includes things like systems analysis, databases, security, and documentation. Also realize that C++ isn't the only language out there, you should be able to jump fairly quickly from language to language. Don't get stuck in one language. Learn the basics of other languages including web based. In addition to code, focus on your humanities. Nobody wants to interact with a dull uncultured nerd. Take classes that interest you and will provide you with a good non-technical education as well.
A new algorithm designed at the University of Toronto has the power to profoundly change the way we find photos among the billions on social media sites such as Facebook and Flickr. This month, the United States Patent and Trademark Office will issue a patent on this technology.
Imagine you and your mother are pictured together, building a sandcastle at the beach. You're both tagged in the photo quite close together. In the next photo, you and your father are eating watermelon. You're both tagged. Because of your close 'tagging' relationship with both your mother in the first picture and your father in the second, the algorithm can determine that a relationship exists between those two and quantify how strong it may be.
In a third photo, you fly a kite with both parents, but only your mother is tagged. Given the strength of your 'tagging' relationship with your parents, when you search for photos of your father the algorithm can return the untagged photo because of the very high likelihood he's pictured.
"Two things are happening: we understand relationships, and we can search images better," says Professor Aarabi.
The nimble algorithm, called relational social image search, achieves high reliability without using computationally intensive object- or facial-recognition software. "If you want to search a trillion photos, normally that takes at least a trillion operations. It's based on the number of photos you have," says Aarabi. "Facebook has almost half a trillion photos, but a billion users -- it's almost a 500 order of magnitude difference. Our algorithm is simply based on the number of tags, not on the number of photos, which makes it more efficient to search than standard approaches."
Work on this project began in 2005 in Professor Aarabi's Mobile Applications Lab, Canada's first lab space for mobile application development.
Currently the algorithm's interface is primarily for research, but Aarabi aims to see it incorporated on the back-end of large image databases or social networks. "I envision the interface would be exactly like you use Facebook search -- for users, nothing would change. They would just get better results," says Aarabi.
While testing the algorithm, Aarabi and Appel discovered an unforeseen application: a new way to generate maps. They tagged a few photographs of buildings around the University of Toronto and ran them through the system with a bunch of untagged campus photos. "The result we got was of almost a pseudo-map of the campus from all these photos we had taken, which was very interesting," says Aarabi.
This work received support from the National Science and Engineering Research Council of Canada. It will be presented at the IEEE International Symposium on Multimedia Dec. 10, 2013.
Google's C-like language, designed (according to one of its creators) for writing "big software," recently reached two distinct milestones: Version 1.2 of the language was released on Dec. 1, and the language itself is now 4 years old, having been released to the public as an open source project under a BSD-style license on Nov. 10, 2009.
So why create Go -- let alone program in it -- especially when C/C++ still enjoy such widespread use? Google claims Go was devised to take advantage of multicore processors, provide modern language features such as dynamic typing and garbage collection, and get rid of many of the burdensome aspects of C-like languages (e.g., include files). It compiles quickly and promises a high degree of performance. (A recent set of benchmarks clocked Go 1.1.2 against C using the gcc compiler on x64 Ubuntu.)
Google has a whole welter of justifications for Go as a go-to language for many problem domains. The Go project's FAQnotes that "no major systems language has emerged in over a decade, but over that time the computing landscape has changed tremendously." HP cloud software engineer Matt Farina has written that Go's benefits stem from it being "engineered" rather than "hacked together over time."
The problem is whether Google's ambitions for the language will be matched by its uptake amongst developers.
When word of Go first started circulating, InfoWorld's Neil McAllister felt it was "a nonstarter," and pointed out that Go being open source doesn't make it any less tied to Google (look at MySQL and Oracle). "Developers should be loyal to good code first and foremost, not to the companies that provide their tools," he wrote.
However, those companies that have used Go in some high-profile production contexts tell a different story than the statistics. Braintree Payment Solutions gave Go a try earlier this year and liked what it saw -- although not enough to keep the company from rewriting the Go-based app in another language. "[Go's] ecosystem for developing web applications is still extremely immature," Braintree wrote, citing problems with Go's database libraries and the lack of robustness in its Web framework compared to solutions like Rails or Django.
In the post Common Red Flags in Java Development I looked at some practices that are not necessarily wrong or incorrect in and of themselves, but can be indicative of potentially greater problems. These "red flags" are similar to the concept of "code smells" and some of the particular "red flags" I cite in this post have been called "code smells." As I stated in the initial post, several of these "red flags" are considered significant enough that static code analysis tools and Java IDEs will flag them.
"Logging" Messages Directly to stdout or stderr
Logging frameworks have been available for a long time in Java and today we have a wide variety of logging frameworks(some of which build on each other) including traditional Log4j 1.2, log4j 2, java.util.logging (Java Logging API), Apache Commons Logging, and SLF4J. Given this, it surprises me when I see System.out and System.err references in Java code.
There are multiple reasons that the existence of Java code directly writing to standard output or standard error is of concern. One reason for concern is that this might mean immature code that was intended to later be changed to logging but never got that finishing attention. Another disadvantage of referencing standard output and standard error is that the "logged" messages will likely not appear in the log files with the rest of the logs written by logging frameworks. A third problem is that there are numerous nice features provided by a logging framework that are not provided by simple writing to standard output and standard error. These include the abilignment, and ability to easily redirect the output to different destinations and with different formats. Although all of this can be manually done when working directly with output and error streams, it requires customized work rather than being available "out of the box."
There are manifestations in Java code that write to standard output and standard error other than direct access using
System.err (though they typically implicitly
System.err). For example,Throwable.printStackTrace() [more commonly used in handling of Exceptions], as its Javadoc states, "Prints this throwable and its backtrace to the standard error stream."
Use of StringBuffer Rather than StringBuilder
This is admittedly a very minor thing, but it can indicate outdated Java code (StringBuffer introduced in JDK 1.0 andStringBuilder introduced in J2SE 5) or Java code where the developer did not understand the the differences betweenStringBuffer and StringBuilder. In most cases, the performance difference between the two is not significant to the application at hand, but because StringBuilder is preferable in most cases where I've seen StringBuffer used, one may as well enjoy the typically slight performance benefit of using
StringBuilder. I'm having a difficult time recalling a single instance in which I have seen
StringBuffer used in which
StringBuilder can be used instead. A related red flag is mixing String concatenation with a StringBuilder in its constructor or overloaded append methods.
Too Many Parameters in Methods and Constructors
I'm always concerned about a method or constructor not being used correctly by its clients when the method or constructor has too many parameters, especially if several of the parameters are of the same type. If a method accepts three
Strings and three
booleans, for example, it is easy for the client to mix up the particular values it passes in. The compiler cannot help much in this case and the only way to detect the source of the problem (or even if a problem exists at all) is at runtime (via unit tests or other tests or, sadly, during regular execution of the software). Too many parameters can be a "red flag" for improper design as well. I am not going to look at this "red flag" any deeper in this post because I have already covered this "red flag," multiple ways to resolve it, and issues it presents in a series of eight blogs posts.
- Too Many Parameters in Java Methods, Part 1: Custom Types
- Too Many Parameters in Java Methods, Part 2: Parameters Object
- Too Many Parameters in Java Methods, Part 3: Builder Pattern
- Too Many Parameters in Java Methods, Part 4: Overloading
- Too Many Parameters in Java Methods, Part 5: Method Naming
- Too Many Parameters in Java Methods, Part 6: Method Returns
- Too Many Parameters in Java Methods, Part 7: Mutable State
- Too Many Parameters in Java Methods, Part 8: Tooling
Excessive Explicit Casting
Explicit casting is probably one of the best examples of a red flag situation in which the casting itself may not affect any functionality or logic from working correctly, but is a tip-off that things are not as well as they could be. Casting can imply poor design choices (such as not using polymorphism correctly, using inheritance when inappropriate, or forcing things to go together that were never design to go together). Explicit casting is certainly appropriate or required in many situations (such as when obtaining a Spring Framework context bean), but explicit casting can also be used as a crutch to get things working that have not been designed as carefully as they could have been. Casting can also be indicative of APIs that are too broad or interfaces used in APIs that are too broad (highlighted in the next item).
Use of Too Broad of an Interface or Class
I have often seen the Collection interface used as a method parameter or return type when Set or List or even more specific interface was more appropriate. For example, a method that returns a
Collection but expects the client code to know that the returned
Collection is ordered, should return a
List or more specific interface or implementation of
List. Likewise, if a sorted
Set is expected by a method, it should advertise the method as expecting a SortedSet or similar interface or implementation class. When the interface or class returned or expected as a parameter is too broad for the given contract, somebody is forced to "know" that's the case and to cast to the appropriate level to get the functionality that they are dependent on.
Using the appropriate level or interface or class goes beyond helping avoid unnecessary explicit casting. The appropriate type level advertises and enforces the method contract better than mere documentation can. However, it goes further than that. In some cases, significant runtime exceptions can occur when the advertised interface is too broad to capture assumptions in the method's contract. For example, a generic interface might optionally support a method but the actual implementation of that interface throws an UnsupportedOperationException when called because it does not implement that optional method. Between
UnsupportedOperationExceptions and ClassCastExceptions, use of overly broad interfaces or classes can lead to potentially serious runtime issues.
This is not to say that interfaces or broad classes should be avoided. Rather, it is to say that the appropriate degree of abstraction should be used in return types and parameter types so that the expected behavior for both sides of the invocation is appropriately advertised and enforced.
Use of List.addAll()
Use of one of the overloaded List.addAll() methods makes me nervous and is a bright red flag when I see it in code. That doesn't mean it's always wrong to use it, but it does seem like I've seen a lot of bloated memory issues due to misuse of this. Because
Lists will add "duplicate" objects as much as the developer likes, errant code can exponentially fill these
Lists up with redundant objects. Negative impacts from this range from potentially impeded performance to running out of memory. When I see use of
List.addAll(), I carefully review the code and unit test it extra carefully to ensure that its memory consumption doesn't get out of control. As described in the previous "red flag," any use of
Collection.addAll() must be analyzed similarly to
List.addAll() until it is known for certain that the
Collection is really not a
Perhaps the best example of all for me of a "red flag" is the frequent use of idioms and code conventions that are contrary or significantly different to "generally accepted Java coding standards." Nothing about using names, case, or other style issues directly impact the correctness or performance of the code. However, these discrepancies remain a "red flag" warning of potential actual problems with logic or performance because use of these significantly non-standard idioms and conventions imply that the developer may be new to Java and hence may have made mistakes common to those new to Java. A good article on the important of writing Java code "without an accent" is Speaking the Java language without an accent. In that article, author Elliotte Rusty Harold writes about how such code is more difficult to read and maintain.
In relatively rare cases, this can move from a style issue to an impacting issue. This occurs when one writes Java code in a manner that makes most sense in a different language (such as C or C++) but does not make as much sense as alternative approaches in Java.
As was the case in my first post on red flags in Java code, the "red flags" discussed in this post are generally things that are not necessarily incorrect when used in appropriate and select circumstances, but often do indicate that things are not as well as they could be in the greater application.
Software Engineer - Java/Scala
Workday was founded by two visionaries Dave Duffield and Aneel Bhusri (both PeopleSoft veterans) in 2005 with a goal to deliver Human Capital Management, Payroll, Financial Management and Worker Spend Management solutions for midsize and Fortune 500 companies.
Workday is not your average company and we pride ourselves on everything that makes us unique such as our culture, core values, company meetings, development “Geekfests”, commitment to sustainability, recognition programs but most importantly our people. Workday employees are self-disciplined, hard working, curious, trustworthy, humble, and truthful. Workday is the leader in enterprise class, software-as-a-service (SaaS) solutions for the management of global businesses. We are growing fast with offices in the United States (HQ Pleasanton), Canada (Vancouver and Toronto), Europe (Dublin, London, Munich, Sweden and the Netherlands), Hong Kong and Australia.
Workday currently has a position open for a Java/Scala Engineer to work in a highly motivated development team that design, build and own some of the core services behind the Workday Cloud. Research, prototyping, innovation and technical excellence are essential parts of our team culture.
BS in Computer Science or related fields
Team members must have an ongoing interest in new technologies and techniques that can improve our services
5+ years experience in Object Oriented design and Java programming with an interest in functional programming
UNIX or Linux experience
Proven track record of test driven development & automated system testing
Commercial experience with distributed, concurrent, high-performance systems
Interest or experience in one or more of the following is advantageous: Scala, Akka, NoSQL, and Kafka & Zookeeper
The intern will gain practical experience in Cloud based technologies The intern will receive formal/informal training in the following. Both sales and product training will be supplied. On completion the intern will have attained skills in directing and maturing business relationships with regards to growing and enhancing a companies infrastructure.
We are looking for someone who is eager to learn and implement that learning in a team environment. The ideal person will have excellent interpersonal, communication and organisational skills, with good computer literacy. They will have an excellent work ethic and the ability to work on their own initiative but also as part of a team.
This is an Internship. An allowance of €50 per week will be paid in addition to your current Social Welfare payment.See eligibility criteria above.
The Organisation will assign a mentor to support you during the Internship.
Yes, I use Amazon S3 and I didn’t say so just to promote the product for affiliate commission because Amazon don’t provide affiliate program for their S3 storage service.
But why I am still using Amazon S3 here? This doesn’t make sense!
Of course I am here to tell you why but before that, let’s make things worse here by addressing the disadvantages of Amazon S3.
The Disadvantages of Amazon S3
- No Official Desktop Application. You can’t sync your data automatically like those Dropbox desktop application as far as I know. It is not a big problem because there could be 3rd party application that can do it but definitely not Amazon themselves for now.
- The Price is the Same. Since the price of Amazon S3 is not really cheap, this made them a disadvantage. The price of 100 GB in S3 is almost the same for 100 GB in Dropbox. So why not go for Dropbox that is more feature rich.
So now, Why Amazon S3?
The main reason I selected Amazon S3 is because of the ‘Pay As You Go‘ concept.
My problem with paying for cloud storage are:
- I need more than 5 GB (Average free cloud storage space) but not more than 20 GB.
- Minimum subscription for Dropbox is 100 GB for $9.99 per month but I don’t utilize completely.
As a result, Amazon S3 solved my problem because I can utilize more than 5 GB freely and best of all, I don’t have to commit $9.99 every month.
The beauty of ‘Pay As You Go’
By going for ‘Pay As You Go’ concept, you don’t have to under utilize your subscription.
Imagine that you only need 20 GB of cloud storage, you will need to pay the following:
- For Dropbox – $9.99
- For Google Drive – $4.99
- For Skydrive – $10.00
- For Ubuntu One – $2.99
- And finally Amazon S3 – $1.43 (Amazon Calculator)
So back to you now, what cloud storage do you subscribe to?
Cloud computing makes it harder for enterprises to be sure they're complying with industry and government regulations. IT and legal experts offer CIOs advice on how to stay in compliance even when their applications reside in the cloud.
CIO — Cloud computing seems simple in concept, and indeed, simplicity of operation, deployment and licensing are its most appealing assets. But when it comes to questions of compliance, once you scratch the surface you'll find more questions than you asked in the first place, and more to think about than ever before.
Compliance covers a lot of ground, from government regulations such as Sarbanes-Oxley and the European Union Data Protection Act, to industry regulations such as PCI DSS for payment cards and HIPAA for health data. You may have internal controls in place, but moving to a public-cloud infrastructure platform, a cloud-based application suite or something in between will mean giving up some controls to the cloud vendor.
That's a position many auditors—and CIOs and CEOs—find themselves in today. They want to know how to leap into cloud computing in a way that preserves their good standing in regulatory compliance. Here are four tips for keeping tabs on compliance in the cloud, from analysts, vendors and consultants.
1. Be aware of new challenges the cloud may add to your IT workload.
When you evaluate cloud vendors, start by looking for sound practices and strategies for user identity and access management, data protection and incident response. These are baseline compliance requirements. Then, as you map specific compliance requirements to your prospective cloud vendor's controls, you'll likely face some cloud-specific challenges.
Data location is one. The EU Data Protection Act, for example, strives to keep personal information within the European Union. To comply, your cloud vendor should keep your European customer data on servers located in Europe.
Multi-tenancy and de-provisioning also pose challenges. Public cloud providers use multi-tenancy to optimize server workloads and keep costs down. But multi-tenancy means you're sharing server space with other businesses, so you should know what safeguards your cloud provider has in place to prevent any compromise. Depending on how critical your data is, you may also want to use encryption. HIPAA, for example, requires that all user data, both moving and at rest, be encrypted.
User de-provisioning is an issue that will become more challenging as password-authentication methods grow in complexity and volume. Federated identity management schemes will make it easier for users to log on to multiple clouds, and that will make de-provisioning much trickier.
"When an employee leaves the company, what you'd like is to push a button and that person gets de-provisioned from their Windows account and any internal enterprise applications, their mobile phone gets wiped of corporate information, and they're blocked from the company's SaaS applications, " says Tom Kemp, CEO of Centrify, a provider of identity management and compliance tools. Today, automated de-provisioning can't span both cloud and on-premise systems, he says.