    
|
PAID Sustainability Outreach Intern (Spring 2014)
DESCRIPTION: The Sustainability Outreach Intern at Off-Campus Student Services will promote, support, and raise awareness about sustainability as it relates to commuter students. To accomplish this, the intern will assist in the design and delivery of social and educational events related to alternative transportation (e.g., UMBC Transit Shuttles, MTA public transportation, carpooling, zipcar, etc.) and recycling. Also, the intern will collaborate on events with other UMBC department and student leaders. Through social media and other digital advertising avenues, the intern will promote UMBC’s sustainability initiatives and assist with UMBC’s new Casual Carpoolingcommunity. Work hours: approximately 8 hours per week.
QUALIFICATIONSBENEFITS:
To apply, you need to have your resume reviewed and approved by a Coordinator at The Shriver Center. Please call their front desk at 410-455-2493 for an appointment or contact shrivercenter@umbc.edu, umbcworks@umbc.edu for more information. The internship listing can be found at UMBCworks (ID#: 9262157). The deadline to apply is January 24, 2014. Submit your resume through UMBCworks. Submit your cover letter and unofficial transcript to Jessica Sadler, OCSS Graduate Assistant, jsadler1@umbc.edu.
]]>|
|
|
|
 |
To celebrate the long-awaited release of our new Smashing Book (yaaaay!), we’ve prepared a little mystery for you. Below you’ll find an animated GIF that contains a hidden message. Once you resolved the mystery, you’ll see a Twitter hashtag displayed in plain text.
Are you ready? Action! (Hint: watch out for the file name).
A hint: watch out for the file name.
Among the first readers who tweet us with the hashtag we’ll raffle a quite extraordinary, smashing prize (and a couple of other Smashing extras):
Please notice that to avoid spoilers, comments are closed for this post. And sorry, we aren’t going to make it too easy for you. Alright. Let’s get to work. Have you figured it out yet? ;-)
© Vitaly Friedman for Smashing Magazine, 2013.
]]>|
|
Can you imagine your company having a chief electricity officer? Seems ridiculous doesn’t it, but many large businesses did when electricity first started to power the industrial economy.
Electricity is such an integral part of our working life that it is impossible to imagine life without it. Companies just couldn’t operate without power, but it wasn’t always that way. Many business leaders failed to grasp the full potential of electricity after it was first introduced. Over a decade after introducing electricity, they were still building factories by water, despite no longer needing it to power their machinery. These business leaders needed help integrating the new technology into their thinking and that is where the chief electricity officer came in.
Although we may scoff at the foolish industrialists with their shortsighted vision, most companies are making exactly the same mistake today with the Web. They are failing to grasp the potential of the Web to revolutionize every aspect of their business. Instead, many have reduced the Web to a marketing tool.
What organizations need is the digital equivalent of a chief electricity officer. They need somebody who will champion digital across the organization until it is as ubiquitous as electricity in the modern work place. Many organizations require a digital evangelist sitting on the board (even if only in a non-executive and part-time capacity) so that digital is fully utilized. However, this should only a temporary requirement.
As I have already pointed out, we don’t need chief electricity officers anymore. Once electricity was fully integrated into the organizational processes and culture, their role became superfluous. The same should be true of us as Web professionals.
The Web has much more potential than most of us tend to believe. All you need is to take a closer look. (Image credits: opensourceway)
Whether part of an internal Web team or an external developer, our eventual aim should be to make our role redundant, once digital is a part of daily working life. Once that happens you would no longer need a digital team in the same way as we no longer need a chief electricity officer.
I am aware this may sound like a rather extreme position. It is hard to imagine a world where this is a reality, but I believe we may one day get there. Whether we do is not really the point. The point is that the way we perceive our job is so important and that at the moment the emphasis is slightly wrong.
At the moment, most Web professionals see their job as executing some form of digital strategy. It falls to them to build, maintain and run digital assets from websites to mobile apps. Sometimes we facilitate the contribution of others through the use of a content management system, but ultimately we feel we should ‘own’ digital.
In fact, I have heard many argue that internal Web teams don’t have enough ownership over the Web (something I have written myself) and that external teams are seen as implementors rather than providing more of a leadership role. I have also heard many argue that organizations need a digital strategy and that digital teams should be more empowered within organizations.
All of these arguments I agree with, but feel that although true, they miss the point. Yes, right now we need a strong digital team. Yes, organizations should use external contractors as more than implementors and yes companies need to think about their strategy towards digital. However, these are all transitionary principles. They are merely stepping stones towards a greater aim, which is to make digital ubiquitous within the organization. In the end, we need a business strategy that includes digital, rather than a separate digital strategy.
If we believe our objective is to make digital ubiquitous, then our primary role as Web professionals is knowledge transfer. It falls to us to teach those within the organizations with which we work, about the potential and power of digital. Ultimately is not our job to own digital or just to build digital assets. Our job is to teach others how to own digital and put in place the assets they need. In the short term this may involve us leading by example. We may need to set a strong digital direction and take ownership over digital as a chief electricity officer did, but eventually we will need to let go of the reins.
Furthermore, if we see our role as educators, facilitators and evangelists then we approach things with a different attitude. Its not about building our digital empire within an organization and wrestling control from the ignorant colleagues that “don’t get digital”. Equally as an external contract our aim is not to ensure a long term revenue stream from clients by making them reliant on our services. Instead it is about facilitating others through improving their understanding of digital.
Digital strategy always requires focus on the essential — on what matters most. (Image credits: opensourceway)
Don’t get me wrong. Many organizations need strong central leadership over digital and the Web team is the place for that. Equally, I have no problem with agencies who work in long-term partnership with clients if that is what is right for the client. However, ultimately we need to be willing to step aside when we have become a bottleneck and when the organization has reached a point when digital is deep rooted across the entire company.
It’s time for you to honestly ask yourself what your agenda is. Is it to help organizations facilitate their use of digital or are you more concerned with securing your own position? If it is the latter I would challenge you to think again. By facilitating others and focusing on knowledge transfer you will become the go-to person for innovation and the next big thing. Become so concerned with your own job and you will be the roadblock everybody has to work around to get things done.
Even after 20 years of the Web, we are still at the beginning of a transformation from an industrial to digital economy. Adapting to this change is a huge undertaking for most organizations and we can either be facilitators of that change or we can isolate ourselves as some kind of digital elite.
I know which I choose. What about you?
Editor’s Note: Paul Boag is writing a new Smashing book on “Digital Adaptation” with guidelines for adapting a business for the digital economy. Coming out in March 2014. If you like, you can subscribe for email updates to be among the first ones to know!
(il)
© Paul Boag for Smashing Magazine, 2013.
]]>The Repository Design Pattern, defined by Eric Evens in his Domain Driven Design book, is one of the most useful and most widely applicable design patterns ever invented. Any application has to work with persistence and with some kind of list of items. These can be users, products, networks, disks, or whatever your application is about. If you have a blog for example, you have to deal with lists of blog posts and lists of comments. The problem that all of these list management logics have in common is how to connect business logic, factories and persistence.
As we mentioned in the introductory paragraph, a Repository will connect Factories with Gateways (persistence). These are also design patterns and if you are not familiar with them, this paragraph will shed some light on the subject.
A factory is a simple design pattern that defines a convenient way to create objects. It is a class or set of classes responsible for creating the objects our business logic needs. A factory traditionally has a method called " and it will know how to take all the information needed to build an object and do the object building itself and return a ready-to-use object to the business logic.make()"
Here is a little bit more on the Factory Pattern in an older Nettuts+ tutorial: A Beginner’s Guide to Design Patterns. If you prefer a deeper view on the Factory Pattern, check out the first design pattern in the Agile Design Patterns course we have on Tuts+.
Also known as “Table Data Gateway” is a simple pattern that offers the connection between the business logic and the database itself. Its main responsibility is to do the queries on the database and provide the retrieved data in a data structure typical for the programming language (like an array in PHP). This data is then usually filtered and modified in the PHP code so that we can obtain the information and variables needed to crate our objects. This information must then be passed to the Factories.
The Gateway Design Pattern is explained and exemplified in quite great detail in a Nettuts+ tutorial about Evolving Toward a Persistence Layer. Also, in the same Agile Design Patterns course the second design pattern lesson is about this subject.
It may not be obvious at first sight, but connecting Gateways to Factories can lead to a lot of duplication. Any considerable sized software needs to create the same objects from different places. In each place you will need to use the Gateway to retrieve a set of raw data, filter and work that data to be ready to be sent to the Factories. From all these places, you will call the same factories with the same data structures but obviously with different data. Your objects will be created and provided to you by the Factories. This will, inevitably lead to a lot of duplication in time. And the duplication will be spread throughout distant classes or modules and will be difficult to notice and to fix.
Another problem we have is how to express the queries we need to do with the help of the Gateways. Each time we need some information from the Gateway we need to think about what do we exactly need? Do we need all the data about a single subject? Do we need only some specific information? Do we want to retrieve a specific group from the database and do the sorting or refined filtering in our programming language? All of these questions need to be addressed each time we retrieve information from the persistence layer through our Gateway. Each time we do this, we will have to come up with a solution. In time, as our application grows, we will be confronted with the same dilemmas in different places of our application. Inadvertently we will come up with slightly different solutions to the same problems. This not only takes extra time and effort but also leads to a subtle, mostly very difficult to recognize, duplication. This is the most dangerous type of duplication.
In the previous two paragraphs we talked only about data retrieval. But the Gateway is bidirectional. Our business logic is bidirectional. We have to somehow persist our objects. This again leads to a lot of repetition if we want to implement this logic as needed throughout different modules and classes of our application.
A Repository can function in two ways: data retrieval and data persistence.
When used to retrieve objects from persistence, a Repository will be called with a custom query. This query can be a specific method by name or a more common method with parameters. The Repository is responsible to provide and implement these query methods. When such a method is called, the Repository will contact the Gateway to retrieve the raw data from the persistence. The Gateway will provide raw object data (like an array with values). Then the Repository will take this data, do the necessary transformations and call the appropriate Factory methods. The Factories will provide the objects constructed with the data provided by the Repository. The Repository will collect these objects and return them as a set of objects (like an array of objects or a collection object as defined in the Composite Pattern lesson in the Agile Design Patterns course).
The second way a Repository can work is to provide the logic needed to be done in order to extract the information from an object and persist it. This can be as simple as serializing the object and sending the serialized data to the Gateway to persist it or as sophisticated as creating arrays of information with all the fields and state of an object.
When used to persist information the client class is the one directly communicating with the Factory. Imagine a scenario when a new comment is posted to a blog post. A Comment object is created by our business logic (the Client class) and then sent to the Repository to be persisted. The repository will persist the objects using the Gateway and optionally cache them in a local in memory list. Data needs to be transformed because there are only rare cases when real objects can be directly saved to a persistence system.
The image below is a higher level view on how to integrate the Repository between the Factories, the Gateway and the Client.
In the center of the schema is our Repository. On the left, is an Interface for the Gateway, an implementation and the persistence itself. On the right, there is an Interface for the Factories and a Factory implementation. Finally, on the top there is the client class.
As it can be observed from the direction of the arrows, the dependencies are inverted. Repository only depend on the abstract interfaces for Factories and Gateways. Gateway depends on its interface and the persistence it offers. The Factory depends only on its Interface. The client depends on Repository, which is acceptable because the Repository tends to be less concrete than the Client.
Put in perspective, the paragraph above respects our high level architecture and the direction of dependencies we want to achieve.
Now that we’ve seen the theory, it is time for a practical example. Imagine we have a blog where we have Post objects and Comment objects. Comments belong to Posts and we have to find a way to persist them and to retrieve them.
We will start with a test that will force us to think about what our Comment object should contain.
class RepositoryTest extends PHPUnit_Framework_TestCase {
function testACommentHasAllItsComposingParts() {
$postId = 1;
$commentAuthor = "Joe";
$commentAuthorEmail = "joe@gmail.com";
$commentSubject = "Joe Has an Opinion about the Repository Pattern";
$commentBody = "I think it is a good idea to use the Repository Pattern to persist and retrieve objects.";
$comment = new Comment($postId, $commentAuthor, $commentAuthorEmail, $commentSubject, $commentBody);
}
}
At first glance, a Comment will just be a data object. It may not have any functionality, but that is up to the context of our application to decide. For this example just assume it is a simple data object. Constructed with a set of variables.
class Comment {
}
Just by creating an empty class and requiring it in the test makes it pass.
require_once '../Comment.php';
class RepositoryTest extends PHPUnit_Framework_TestCase {
[ ... ]
}
But that’s far from perfect. Our test does not test anything yet. Let’s force ourselves to write all the getters on the Comment class.
function testACommentsHasAllItsComposingParts() {
$postId = 1;
$commentAuthor = "Joe";
$commentAuthorEmail = "joe@gmail.com";
$commentSubject = "Joe Has an Opinion about the Repository Pattern";
$commentBody = "I think it is a good idea to use the Repository Pattern to persist and retrieve objects.";
$comment = new Comment($postId, $commentAuthor, $commentAuthorEmail, $commentSubject, $commentBody);
$this->assertEquals($postId, $comment->getPostId());
$this->assertEquals($commentAuthor, $comment->getAuthor());
$this->assertEquals($commentAuthorEmail, $comment->getAuthorEmail());
$this->assertEquals($commentSubject, $comment->getSubject());
$this->assertEquals($commentBody, $comment->getBody());
}
To control the length of the tutorial, I wrote all the assertions at once and we will implement them at once as well. In real life, take them one by one.
class Comment {
private $postId;
private $author;
private $authorEmail;
private $subject;
private $body;
function __construct($postId, $author, $authorEmail, $subject, $body) {
$this->postId = $postId;
$this->author = $author;
$this->authorEmail = $authorEmail;
$this->subject = $subject;
$this->body = $body;
}
public function getPostId() {
return $this->postId;
}
public function getAuthor() {
return $this->author;
}
public function getAuthorEmail() {
return $this->authorEmail;
}
public function getSubject() {
return $this->subject;
}
public function getBody() {
return $this->body;
}
}
Except for the list of private variables, the rest of the code was generated by my IDE, NetBeans, so testing the auto generated code may be a little bit of overhead some times. If you are not writing these lines by yourself, feel free to do them directly and don’t bother with tests for setters and constructors. Nevertheless, the test helped us better expose our ideas and better document what our Comment class will contain.
We can also consider these test methods and test classes as our “Client” classes from the schemas.
To keep this example as simple as possible, we will implement only an InMemoryPersistence so that we do not complicate our existence with file systems or databases.
require_once '../InMemoryPersistence.php';
class InMemoryPersistenceTest extends PHPUnit_Framework_TestCase {
function testItCanPerisistAndRetrieveASingleDataArray() {
$data = array('data');
$persistence = new InMemoryPersistence();
$persistence->persist($data);
$this->assertEquals($data, $persistence->retrieve(0));
}
}
As usual, we start with the simplest test that could possibly fail and also force us to write some code. This test creates a new InMemoryPersistence object and tries to persist and retrieve an array called data.
require_once __DIR__ . '/Persistence.php';
class InMemoryPersistence implements Persistence {
private $data = array();
function persist($data) {
$this->data = $data;
}
function retrieve($id) {
return $this->data;
}
}
The simplest code to make it pass is just to keep the incoming $data in a private variable and return it in the retrieve method. The code as it is right now does not care about the sent in $id variable. It is the simplest thing that could possibly make the test pass. We also took the liberty to introduce and implement an interface called Persistence.
interface Persistence {
function persist($data);
function retrieve($ids);
}
This interface defines the two methods any Gateway needs to implement. Persist and retrieve. As you probably already guessed, our Gateway is our InMemoryPersistence class and our physical persistence is the private variable holding our data in the memory. But let’s get back to the implementation of this in memory persistence.
function testItCanPerisistSeveralElementsAndRetrieveAnyOfThem() {
$data1 = array('data1');
$data2 = array('data2');
$persistence = new InMemoryPersistence();
$persistence->persist($data1);
$persistence->persist($data2);
$this->assertEquals($data1, $persistence->retrieve(0));
$this->assertEquals($data2, $persistence->retrieve(1));
}
We added another test. In this one we persist two different data arrays. We expect to be able to retrieve each of them individually.
require_once __DIR__ . '/Persistence.php';
class InMemoryPersistence implements Persistence {
private $data = array();
function persist($data) {
$this->data[] = $data;
}
function retrieve($id) {
return $this->data[$id];
}
}
The test forced us to slightly alter our code. We now need to add data to our array, not just replace it with the one sent in to persists(). We also need to consider the $id parameter and return the element at that index.
This is enough for our InMemoryPersistence. If needed, we can modify it later.
We have a Client (our tests), a persistence with a Gateway, and Comment objects to persists. The next missing thing is our Factory.
We started our coding with a RepositoryTest file. This test, however, actually created a Comment object. Now we need to create tests to verify if our Factory will be able to create Comment objects. It seems like we had an error in judgment and our test is more likely a test for our upcoming Factory than for our Repository. We can move it into another test file, CommentFactoryTest.
require_once '../Comment.php';
class CommentFactoryTest extends PHPUnit_Framework_TestCase {
function testACommentsHasAllItsComposingParts() {
$postId = 1;
$commentAuthor = "Joe";
$commentAuthorEmail = "joe@gmail.com";
$commentSubject = "Joe Has an Opinion about the Repository Pattern";
$commentBody = "I think it is a good idea to use the Repository Pattern to persist and retrieve objects.";
$comment = new Comment($postId, $commentAuthor, $commentAuthorEmail, $commentSubject, $commentBody);
$this->assertEquals($postId, $comment->getPostId());
$this->assertEquals($commentAuthor, $comment->getAuthor());
$this->assertEquals($commentAuthorEmail, $comment->getAuthorEmail());
$this->assertEquals($commentSubject, $comment->getSubject());
$this->assertEquals($commentBody, $comment->getBody());
}
}
Now, this test obviously passes. And while it is a correct test, we should consider modifying it. We want to create a Factory object, pass in an array and ask it to create a Comment for us.
require_once '../CommentFactory.php';
class CommentFactoryTest extends PHPUnit_Framework_TestCase {
function testACommentsHasAllItsComposingParts() {
$postId = 1;
$commentAuthor = "Joe";
$commentAuthorEmail = "joe@gmail.com";
$commentSubject = "Joe Has an Opinion about the Repository Pattern";
$commentBody = "I think it is a good idea to use the Repository Pattern to persist and retrieve objects.";
$commentData = array($postId, $commentAuthor, $commentAuthorEmail, $commentSubject, $commentBody);
$comment = (new CommentFactory())->make($commentData);
$this->assertEquals($postId, $comment->getPostId());
$this->assertEquals($commentAuthor, $comment->getAuthor());
$this->assertEquals($commentAuthorEmail, $comment->getAuthorEmail());
$this->assertEquals($commentSubject, $comment->getSubject());
$this->assertEquals($commentBody, $comment->getBody());
}
}
We should never name our classes based on the design pattern they implement, but Factory and Repository represent more than just the design pattern itself. I personally have nothing against including these two words in our class’s names. However I still strongly recommend and respect the concept of not naming our classes after the design patterns we use for the rest of the patterns.
This test is just slightly different from the previous one, but it fails. It tries to create a CommentFactory object. That class does not exist yet. We also try to call a make() method on it with an array containing all the information of a comment as an array. This method is defined in the Factory interface.
interface Factory {
function make($data);
}
This is a very common Factory interface. It defined the only required method for a factory, the method that actually creates the objects we want.
require_once __DIR__ . '/Factory.php';
require_once __DIR__ . '/Comment.php';
class CommentFactory implements Factory {
function make($components) {
return new Comment($components[0], $components[1], $components[2], $components[3], $components[4]);
}
}
And CommentFactory implements the Factory interface successfully by taking the $components parameter in its make() method, creates and returns a new Comment object with the information from there.
We will keep our persistence and object creation logic as simple as possible. We can, for this tutorial, safely ignore any error handling, validation and exception throwing. We will stop here with the persistence and object creation implementation.
As we’ve seen above, we can use a Repository in two ways. To retrieve information from persistence and also to persist information on the persistence layer. Using TDD it is, most of the time, easier to start with the saving (persisting) part of the logic and then use that existing implementation to test data retrieval.
require_once '../../../vendor/autoload.php';
require_once '../CommentRepository.php';
require_once '../CommentFactory.php';
class RepositoryTest extends PHPUnit_Framework_TestCase {
protected function tearDown() {
\Mockery::close();
}
function testItCallsThePersistenceWhenAddingAComment() {
$persistanceGateway = \Mockery::mock('Persistence');
$commentRepository = new CommentRepository($persistanceGateway);
$commentData = array(1, 'x', 'x', 'x', 'x');
$comment = (new CommentFactory())->make($commentData);
$persistanceGateway->shouldReceive('persist')->once()->with($commentData);
$commentRepository->add($comment);
}
}
We use Mockery to mock our persistence and inject that mocked object to the Repository. Then we call add() on the repository. This method has a parameter of type Comment. We expect the persistence to be called with an array of data similar to $commentData.
require_once __DIR__ . '/InMemoryPersistence.php';
class CommentRepository {
private $persistence;
function __construct(Persistence $persistence = null) {
$this->persistence = $persistence ? : new InMemoryPersistence();
}
function add(Comment $comment) {
$this->persistence->persist(array(
$comment->getPostId(),
$comment->getAuthor(),
$comment->getAuthorEmail(),
$comment->getSubject(),
$comment->getBody()
));
}
}
As you can see, the add() method is quite smart. It encapsulates the knowledge about how to transform a PHP object into a plain array usable by the persistence. Remember, our persistence gateway usually is a general object for all of our data. It can and will persist all the data of our application, so sending to it objects would make it do too much: both conversion and effective persistence.
When you have an InMemoryPersistence class like we do, it is very fast. We can use it as an alternative to mocking the gateway.
function testAPersistedCommentCanBeRetrievedFromTheGateway() {
$persistanceGateway = new InMemoryPersistence();
$commentRepository = new CommentRepository($persistanceGateway);
$commentData = array(1, 'x', 'x', 'x', 'x');
$comment = (new CommentFactory())->make($commentData);
$commentRepository->add($comment);
$this->assertEquals($commentData, $persistanceGateway->retrieve(0));
}
Of course if you do not have an in-memory implementation of your persistence, mocking is the only reasonable way to go. Otherwise your test will be just too slow to be practical.
function testItCanAddMultipleCommentsAtOnce() {
$persistanceGateway = \Mockery::mock('Persistence');
$commentRepository = new CommentRepository($persistanceGateway);
$commentData1 = array(1, 'x', 'x', 'x', 'x');
$comment1 = (new CommentFactory())->make($commentData1);
$commentData2 = array(2, 'y', 'y', 'y', 'y');
$comment2 = (new CommentFactory())->make($commentData2);
$persistanceGateway->shouldReceive('persist')->once()->with($commentData1);
$persistanceGateway->shouldReceive('persist')->once()->with($commentData2);
$commentRepository->add(array($comment1, $comment2));
}
Our next logical step is to implement a way to add several comments at once. Your project may not require this functionality and it is not something required by the pattern. In fact, the Repository Pattern only says that it will provide a custom query and persistence language for our business logic. So if our bushiness logic feels the need of adding several comments at once, the Repository is the place where the logic should reside.
function add($commentData) {
if (is_array($commentData))
foreach ($commentData as $comment)
$this->persistence->persist(array(
$comment->getPostId(),
$comment->getAuthor(),
$comment->getAuthorEmail(),
$comment->getSubject(),
$comment->getBody()
));
else
$this->persistence->persist(array(
$commentData->getPostId(),
$commentData->getAuthor(),
$commentData->getAuthorEmail(),
$commentData->getSubject(),
$commentData->getBody()
));
}
And the simplest way to make the test pass is to just verify if the parameter we are getting is an array or not. If it is an array, we will cycle through each element and call the persistence with the array we generate from one single Comment object. And while this code is syntactically correct and makes the test pass, it introduces a slight duplication that we can get rid of quite easily.
function add($commentData) {
if (is_array($commentData))
foreach ($commentData as $comment)
$this->addOne($comment);
else
$this->addOne($commentData);
}
private function addOne(Comment $comment) {
$this->persistence->persist(array(
$comment->getPostId(),
$comment->getAuthor(),
$comment->getAuthorEmail(),
$comment->getSubject(),
$comment->getBody()
));
}
When all the tests are green, it is alway time for refactoring before we continue with the next failing test. And we did just that with the add() method. We extracted the addition of a single comment into a private method and called it from two different places in our public add() method. This not only reduced duplication but also opened the possibility of making the addOne() method public and letting the business logic decide if it wants to add one or several comments at a time. This would lead to a different implementation of our Repository, with an addOne() and another addMany() methods. It would be a perfectly legitimate implementation of the Repository Pattern.
A Repository provides a custom query language for the business logic. So the names and functionalities of the query methods of a Repository is hugely up to the requirements of the business logic. You build your repository as you build your business logic, as you need another custom query method. However, there are at least one or two methods that you will find on almost any Repository.
function testItCanFindAllComments() {
$repository = new CommentRepository();
$commentData1 = array(1, 'x', 'x', 'x', 'x');
$comment1 = (new CommentFactory())->make($commentData1);
$commentData2 = array(2, 'y', 'y', 'y', 'y');
$comment2 = (new CommentFactory())->make($commentData2);
$repository->add($comment1);
$repository->add($comment2);
$this->assertEquals(array($comment1, $comment2), $repository->findAll());
}
The first such method is called findAll(). This should return all the objects the repository is responsible for, in our case Comments. The test is simple, we add a comment, then another one, and finally we want to call findAll() and get a list containing both comments. This is however not accomplish-able with our InMemoryPersistence as it is at this point. A small update is required.
function retrieveAll() {
return $this->data;
}
That’s it. We added a retrieveAll() method which just returns the whole $data array from the class. Simple and effective. It’s time to implement findAll() on the CommentRepository now.
function findAll() {
$allCommentsData = $this->persistence->retrieveAll();
$comments = array();
foreach ($allCommentsData as $commentData)
$comments[] = $this->commentFactory->make($commentData);
return $comments;
}
findAll() will call the retrieveAll() method on our persistence. That method provides a raw array of data. findAll() will cycle through each element and use the data as necessary to be passed to the Factory. The factory will provide one Comment a time. An array with these comments will be built and returned at the end of findAll(). Simple and effective.
Another common method you will find on repositories is to search for a specific object or group of objects based on their characteristic key. For example, all of our comments are connected to a blog post by a $postId internal variable. I can imagine that in our blog’s business logic we would almost always want to find all the comments related to a blog post when that blog post is displayed. So a method called findByPostId($id) sounds reasonable to me.
function testItCanFindCommentsByBlogPostId() {
$repository = new CommentRepository();
$commentData1 = array(1, 'x', 'x', 'x', 'x');
$comment1 = (new CommentFactory())->make($commentData1);
$commentData2 = array(1, 'y', 'y', 'y', 'y');
$comment2 = (new CommentFactory())->make($commentData2);
$commentData3 = array(3, 'y', 'y', 'y', 'y');
$comment3 = (new CommentFactory())->make($commentData3);
$repository->add(array($comment1, $comment2));
$repository->add($comment3);
$this->assertEquals(array($comment1, $comment2), $repository->findByPostId(1));
}
We just create three simple comments. The first two have the same $postId = 1, the third one has $postID = 3. We add all of them to the repository and then we expect an array with the first two ones when we do a findByPostId() for the $postId = 1.
function findByPostId($postId) {
return array_filter($this->findAll(), function ($comment) use ($postId){
return $comment->getPostId() == $postId;
});
}
The implementation couldn’t be simpler. We find all the comments using our already implemented findAll() method and we filter the array. We have no way to ask the persistence to do the filtering for us, so we will do it here. The code will query each Comment object and compare its $postId with the one we sent in as parameter. Great. The test passes. But I feel we missed something.
function testItCanFindCommentsByBlogPostId() {
$repository = new CommentRepository();
$commentData1 = array(1, 'x', 'x', 'x', 'x');
$comment1 = (new CommentFactory())->make($commentData1);
$commentData2 = array(1, 'y', 'y', 'y', 'y');
$comment2 = (new CommentFactory())->make($commentData2);
$commentData3 = array(3, 'y', 'y', 'y', 'y');
$comment3 = (new CommentFactory())->make($commentData3);
$repository->add(array($comment1, $comment2));
$repository->add($comment3);
$this->assertEquals(array($comment1, $comment2), $repository->findByPostId(1));
$this->assertEquals(array($comment3), $repository->findByPostId(3));
}
Adding a second assertion to obtain the third comment with the findByPostID() method reveals our mistake. Whenever you can easily test extra paths or cases, like in our case with a simple extra assertion, you should. These simple extra assertions or test methods can reveal hidden problems. Like in our case, array_filter() does not reindex the resulting array. And while we have an array with the correct elements, the indexes are messed up.
1) RepositoryTest::testItCanFindCommentsByBlogPostId
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
- 0 => Comment Object (...)
+ 2 => Comment Object (...)
)
Now, you may consider this a shortcoming of PHPUnit or a shortcoming of your business logic. I tend to be rigorous with array indexes because I burned my hands with them a few times. So we should consider the error a problem with our logic in the CommentRepository.
function findByPostId($postId) {
return array_values(
array_filter($this->findAll(), function ($comment) use ($postId) {
return $comment->getPostId() == $postId;
})
);
}
Yep. That simple. We just run the result through array_values() before returning it. It will nicely reindex our array. Mission accomplished.
And that’s mission accomplished for our Repository also. We have a class usable by any other business logic class which offers an easy way to persist and retrieve objects. It also decouples the business logic from the factories and data persistence gateways. It reduced logic duplication and significantly simplifies the persistence and retrieval operations for our comments.
Remember, this design pattern can be used for all types of lists and as you start using it, you will see its usefulness. Basically, whenever you have to work with several objects of the same type, you should consider introducing a Repository for them. Repositories are specialized by object type and not general. So for a blog application, you may have distinct repositories for blog posts, for comments, for users, for user configurations, for themes, for designs, for or anything you may have multiple instances of.
And before concluding this, a Repository may have its own list of objects and it may do a local caching of objects. If an object can not be found in the local list, we retrieve it from the persistence, otherwise we serve it from our list. If used with caching, a Repository can be successfully combined with the Singleton Design Pattern.
As usual, thank you for your time and I sincerely hope I taught you something new today.
]]>It may only be the size of a tall coffee mug, but the launch of Qubscout-S1 on November 21 at 2:10 a.m. represents a big leap forward for UMBC researchers who have long awaited the chance to put a satellite in space.
Qubscout-1 was propelled into a low Earth orbit from a launch site in Yasny, Russia on a Dnepr LV rocket. The satellite was built as a joint venture between the university and Science and Technology Corporation (STC) � a small high-tech company based in Hampton, VA. The satellite measures 2 inches x 2 inches by 4 inches � and it is designed to test a micro sun-sensor that can be used to find and point instruments toward the sun.
UMBC students designed, constructed and tested the sun sensor, while STC built the satellite frame and provided funding for the project. Though the project has been in the works for almost three years, changes in attached payload availability kept the Qubscout-S1 out of orbit until now.
�STC came to us with a launch opportunity in early September 2010 and asked if it was possible to put together a small satellite mission to test a sun-sensor,� says J. Vanderlei Martins, an associate professor of physics who is the principal investigator on the mission. �They needed it in about two months. Our students had already been working on small satellites, so we had the capability and know how. Nonetheless, putting something together this quickly has to be some kind of record.�
After a few months in orbit, the satellite will unfold into a larger configuration to increase its drag and change its rotation rate. The team that built the Qubscout-S1 was able to make the project cost-effective by involving students in production and by building the satellite with materials already available on the market.
�We have a very innovative design that uses commercial off-the shelf materials,� observes Martins.
UMBC students will also stay involved in the project by checking the performance of the sensors installed on the Qubscout-S1, monitoring data transmitted from the satellite to radio receivers at the university.
The satellite that went into orbit on November 21 also represents the fulfillment of the plan set out by the Joint Center for Earth Systems Technology (JCET), which operates in a cooperative agreement between UMBC and the NASA Goddard Space Flight Center (GSFC) at its founding in 1995.
�With the launch of the Qubscout satellite, JCET has now achieved all of the original goals defined when JCET was established in 1995,� says Danita E. Eichenlaub, the administrative director of JCET. �The center congratulates Dr. Vanderlei Martins and his entire team on this accomplishment.�
Adarsh Deepak, the president of STC, also hailed the launch of the Qubscout-1, observing that �this joint venture sets the stage for more exciting collaborations between STC and UMBC in the future. It also shows how small companies, working with a university team, can be part of America�s space future.�
(11/22/2013)
]]>
An amazing season for both UMBC soccer squads finally came to a close in below-freezing temperatures at Retriever Soccer Park on November 24, 2013 when the men�s team � ranked at #5 in the nation � played a 2-2 see-saw second-round NCAA tournament game against the University of Connecticut that ended with the Retrievers bowing out of the tournament on penalty kicks.
Both the men�s and women�s soccer teams had an incredible ride, however �breaking new ground for UMBC�s athletics program while proving that winners on the field can also excel in academics.
The UMBC men�s squad won their NCAA bid � and the right to host the university�s first-ever home game in the tournament � with resounding 4-0 victory against the University of Hartford at Retriever Soccer Park on November 16, 2013. It was a campaign during which the Retriever men also won the America East regular season championship and compiled a 16-1-3 record overall.
The Retriever women�s soccer team ended their season with a hard-fought 2-0 loss in the first round of the women�s NCAA to the fourth-ranked team in the nation � Virginia Tech � in Blacksburg, VA on November 15, 2013.
The UMBC women�s appearance in the NCAA Tournament capped off a reversal of fortune that saw the squad improve from last place to first place in the America East conference, earning a 13-6-2 record, a regular season title and a conference tournament championship along the way. The women�s team bested Stony Brook University 2-1 in the America East final at Retriever Soccer Park On November 9, 2013 to earn an automatic bid to the NCAA tournament.
The success of the UMBC soccer program in 2013 has netted players and coaches numerous honors from the America East conference. Men�s head coach Pete Caringi, Jr. and his staff were voted by the league�s coaches as the Coaching Staff of the Year. Three of the team�s players also received the league�s highest honors, including senior forward Pete Caringi, III (Striker of the Year); senior midfielder Kadeem Dacres (Midfielder of the Year) and junior fullback Oumar Ballo (Defender of the Year).
Women�s head coach Leslie Wray and her staff received the Coaching Staff of The Year award from the America East conference, while junior midfielder Jessy Brown shared Midfielder of the Year honors with Hartford University�s Stephanie Santos. (Brown was also names as the MVP of the America East tournament.)
UMBC soccer players are not just making their mark on the field of play. Both the men�s and women�s teams at the university have matched their success between the lines with excellence in the classroom. In the last round of College Team Academic Awards given by the National College Coaches Association for the 2011-2012 seasons, UMBC was among only 150 schools where both the men�s and women�s teams received this academic honor for having team cumulative grade point averages at 3.0 or higher.
And as the America East conference gave out its individual honors for competition, both women�s team standout Jessy Brown (who has a 3.70 GPA in biology) and junior midfielder Michael DiCesare (who scored the only goal in the November 6 win that clinched the men�s regular season title for UMBC) were also named to the America East�s All-Academic team.
�Our campus takes pride in connecting athletics with the life and academic culture of the university,� says Freeman A. Hrabowski, III, president of UMBC. �The achievements of our women�s and men�s soccer teams this season demonstrate that the concept of a scholar-athlete is alive and well at UMBC.�
Retriever Fever is also catching on among students, alumni and other local college soccer fans. UMBC ranked 13th in attendance nationally among men�s soccer programs, and those numbers are up from 995 in 2012 to 1,228 per game in the current campaign.
For more information on UMBC�s soccer program, visit www.umbcretrievers.com.
(Updated 11/25/2013)
]]>
WordPress, one of the most popular blogging and website platforms in the world, accounts for thousands of new blogs and websites every day.
One of the best ways to get up and running quickly — especially if you don’t have much design or development experience — is to use a theme. And some of the very best themes out there are completely free!
Every month we’ll be bringing you our pick of the best free WordPress themes released in the previous month. Here are our favorites for November:
Unlike many themes which are designed for beginners, this theme with the funny name was created for developers. DevDMBootstrap3 is for developers who are already familiar with Twitter Bootstrap and is a mobile-first theme. The sleek interface makes it easy to develop for the web even quicker.
What’s nice about Fresh Lite is that this responsive theme works using drag and drop tools, making it very easy for beginner WordPress users. The simple theme includes a slider, sidebar and touch-friendly buttons as its top features.
Fruitful is a simple, responsive theme that is built with a lot of options for use. It’s easy to use and style, comes with plenty of options for logos, background images, menus, social icons and a slider. Plus this theme is WooCommerce-ready. You can also customize the CSS.
You get exactly what you expect with Clean Black, a dark minimalist theme. The simple theme includes search, a favicon option and number paging navigation. Clean Black is fully responsive.
Codium Grid is a fully responsive theme that features a super-clean look and feel. It is designed so that the user only has to think about content in the build process. It is customizable in terms of color, backgrounds and header and is widget-ready. (The Instagram widget is particularly nice.) This theme also has some great built-in search engine optimization tools to make getting online a breeze.
Delighted is a highly customizable lightweight theme that’s made just for bloggers. One of the best options is the featured image option, which is available on main and single pages to add an element of sleekness to the overall design. Color and language options are endless with this theme.
GreenPage is a simple blogging theme with a sharp layered look. The theme has plenty of room for featured or thumbnail images, blog posts and sidebar and header navigation.
Aldehyde is a minimally-designed theme with a great above-the-scroll slider to showcase images. The responsive theme also includes bonuses often found only in premium themes such as a parallax header, four different layout options, custom widgets and lots of theme options. Aldehyde also includes powerful social media tools for sharing and links, retina-ready icons and is SEO-ready.
While there are not a large number of free e-commerce themes out there, Shopping does offer some basic sales functionality in a free, WooCommerce-based theme. The simple theme includes plenty of room for product images, prices, ratings and sales information.
This theme takes the trendy “Movember” concept to another level, saying, “not just moustache.” The blogging and portfolio theme is designed in a flat style and includes plenty of neat animation tools and customization options. The responsive theme also supports the Custom Content Portfolio plugin.
Neutro is a responsive theme built in the super-trendy flat design style. What makes this theme unique is that it includes a touch-ready content slider, which is perfect for mobile and tablet devices. Neutro is designed with photos in mind as well with a nice display space. You can customize the theme’s CSS and a variety of other features as well.
Simple and mobile-friendly are the key highlights of OneColumn. The basic theme includes some customization options but nothing fancy. As the name implies, it is designed with a single column for blogging and has room for images, search and recent posts. While this theme might not have enough goodies for more seasoned users, it is perfect for beginners.
While WP Jurist is marketed to legal firms, this fully responsive theme could work for a variety of business types. The design is simple and bold. It includes a slider, widgets and a separate blog template with the option to add author bios. Plus, WP Jurist includes a large number of customization options to help make the theme your own.
This lightweight business-oriented theme features a large header image to attract users. The card-style theme is responsive and has plenty of room to customize it from color to type to different sidebar options.
Hannari is a simple business-oriented theme with a simple design and plenty of bonuses for a free theme. The responsive theme includes tools such as a site map, SEO optimization, a contact form and email newsletter integration. Hannari also includes social media widgets and a variety of customization options so that you can use the theme without worrying that your site will look too much like someone else’s.
Look like a pro blogger with Writr, a responsive theme in the flat design style that is simply beautiful. The theme looks great on a variety of devices and has extras that are often only associated with premium themes. Some of the best bonuses are the custom header, background and gravatar options and post format icons. Writr also includes an infinite scroll, multiple column width options and different sidebar options. The theme is social-media ready as well (with another set of nifty icons) and includes six color palette options.
If a magazine-style theme is your thing, Hueman is a simple theme with a focus on strong visuals. The fully responsive design is modeled in the flat style and is set up for use with high resolution images. This theme makes for a great platform for storytelling or a portfolio.
Modern Real Estate targets real-estate professionals with a plugin that allows for the addition of agent profiles, property listings and customer testimonials. The almost-flat responsive theme has a simple look but can be customized in a variety of ways.
White Paper is a super-light blogging theme. The minimal design is designed to showcase simple text and photo content without a lot of bells and whistles. The theme is responsive and incredibly easy to use, making it a simple choice for first-time bloggers.
This simple dark theme is designed for showcasing photographs and slideshows. The responsive theme includes a nice sidebar option and plenty of social media icons and tools. The rustic background makes this a perfect fit for sites related to nature or the outdoors. The theme allows for customization as well and includes both Facebook and Twitter integration.
This responsive magazine-style theme includes a ton of widgets that make it easy to connect to social media. But the biggest bonus that comes with ProMax is built-in connectivity to Google AdSense and placements for common advertising sizes. The ad-ready features are easy to use and great for a blogger looking to jump into the world of blog revenue generation. ProMax includes a variety of customization options as well, from color to background and customer header and favicon.
Time Turner is designed for designers who still want to work in the skeuomorphic style. The theme features simple textures, shadows and design tricks throughout. The portfolio theme is responsive and offers plenty of great photo and image display spaces. It includes five color options, slider, calendar and search features.
This fully responsive theme is designed for sites that have a focus on news-style content. One of the best features of The Newswire is the large slider. The theme also includes “sticky posts,” multiple navigation options and plenty of color and font customization.
While most of the WordPress themes featured here are for desktop devices or feature responsive templates, WiziApp is designed just for mobile devices. The theme has showcases an app experience for mobile web users and features touch controls for small screens with iPhone, Android and WP8 compatibility. The vertically-based theme includes space for a header image and single column of posts.
Have you used any of these themes? Have we missed one of your favorites? Let us know in the comments.
| Webtones: 1,000 Multimedia Sound Effects Library – only $27! |  |
|
|