Shawn Stratton PHP Geek

22May/11Off

Latex Presentation Template

This is going to be a short post, but thanks to Lorna Jane & Matthew Weier O`Phinney I've been using Latex to generate PDF slides for my upcoming talks.  Over the last few weeks I've been doing a lot of learning in regards to how it works and how to use it more efficiently.  Lorna has an excellent entry in her blog that shows how to actually run latexmk to generate the slides here and another excellent entry on markup here. Matthew Weier O`Phinney and I have been talking about an awesome program on github called pdf-presenter-console which makes life easier as a presenter, it seems like an interesting tool and I'll be covering it at some point more in depth.

On Ubuntu these are the packages you will need:

  1. texlive-publishers texlive-latex-recommended latemk texlive-fonts-extra latex-fonts-recommended

(I may have forgotten one or two but will add if I discover any more)
And here is my template:

\documentclass[style=jefka]{powerdot}
  1. \usepackage{listings}
  2. \usepackage{color}
  3. \usepackage{textcomp}
  4.  
  5. % Code Listing Stuff
  6. \definecolor{lbcolor}{rgb}{0.9,0.9,0.9}
  7. \lstset{  
  8. language=PHP, 
  9. tabsize=2, 
  10. backgroundcolor=\color{lbcolor}, 
  11. rulecolor=, 
  12. extendedchars=true, 
  13. frame=single, 
  14. breakatwhitespace=true, 
  15. breaklines=true, 
  16. identifierstyle=\ttfamily, 
  17. keywordstyle=\color[rgb]{0,0,1}, 
  18. commentstyle=\color[rgb]{0.133,0.545,0.133}, 
  19. stringstyle=\color[rgb]{0.627,0.126,0.941}, 
  20. morekeywords={class, interface, namespace, abstract, new, return, function, public, protected, private, implements, extends, use, as, throws, catch}
  21. }
  22. % Presentation Metadata
  23. \title{Title}
  24. \author{Shawn Stratton}
  25. \date{\today}
  26. \begin{document}
  27.   \maketitle
  28.   \begin{slide}{Slide Title}   
  29.     \begin{itemize}  
  30.       \item Item1  
  31.       \item Item2  
  32.     \end{itemize}
  33.   \end{slide}
  34.   \section{Section Title}
  35.   \begin{slide}{New}  
  36.     \vspace*{\fill}  
  37.     \begin{figure}  
  38.       \centering  
  39.       \includegraphics[width=0.6\slidewidth]{images/sample.eps}  
  40.       \caption{This is a centered (both horizontal & vertical image}  
  41.      \end{figure}  
  42.      \vspace*{\fill}
  43.   \end{slide}
  44.   \begin{note}
  45. This is a note
  46.   \end{note}
  47.   \begin{slide}{Source Inclusion}  
  48.     \vspace*{\fill}  
  49.     \lstinputlisting{src/file.php}  
  50.     \vspace*{\fill}
  51.   \end{slide}
  52. \end{document}

The command to run to generate the presentation:

  1. latexmk -f -pdfps presentation.tex
Filed under: Personal, Tools No Comments
16May/11Off

Accesors and Religion

Today I'm going to become flame bait, I'm going to talk about something that's highly controversial, not because most view points on it are wrong but because everyones differ and they're all wrong besides mine.  Well there went my attempt at being sarcastic, but seriously, this is one of those discussions that will always be highly controversial.

The Problem

Objects have properties which sometimes need special logic on how they are retrieved and set.  There are several solutions to this and everybody has a different view point about which is correct, none are pretty and all have drawbacks which range from writing extra code, creating something that has poor extensibility, or has issues with consistency.  These don't even breach the issues with IDE code completion and analysis.  Lets look at some of these solutions.

The Solutions

Direct Access to properties

So when you first start getting into objects the very first thing that most people do is create a whole bunch of public properties that are accessed like this

class stuff{
  1.   public $whatever;
  2. }
  3. $obj->whatever = 'whatever';

This works well, you can set things outside of the object and then have the object act on it, the problem comes in when you need to modify the way the data is handled when it's set or retrieved without hanging client code.  That's generally when people start writing accessor methods and changing client code which leads to our second solution.

Mixture of Accessors and Direct Property Accessors

Once you start seeing needs of modifying data as it's being assigned you'll start seeing code like this:

class whatever2{
  1.   public $whatever;
  2.   public $stuff;
  3.   public function setWhatever($value);
  4.   public function getWhatever();
  5. }
  6. $obj->stuff = 'stuff';
  7. $obj->setWhatever('whatever');

Usually this only lasts a little while, usually someone will completely forget about the accesor methods and work with the property directly and cause some great inconsistencies, then as an act of paranoia someone will mark the property as protected or private.  This is still a problem as it leads to great inconsistencies, then the next step comes up.

Accessors for everything

This is usually the level most hit and stay at, they start writing accessors for every property that's supposed to be publicly accessible, your code here will start to look like this:

class whatever{
  1.   protected $stuff;
  2.   protected $whatever;
  3.   public function getStuff();
  4.   public function setStuff($value);
  5.   public function getWhatever();
  6.   public function setWhatever($value);
  7. } 
  8. $obj->setStuff('stuff');
  9. $obj->setWhatever('whatever');

At this level consistency is no longer a problem and you can easily extend the functionality of your getters/setters which is awesome, some even figure out to return $this in the setters so they can do chaining, at which point you client code can look like this

  1. $obj->setStuff('stuff')->setWhatever('whatever'):

There are downsides with this though, you'll have to write two methods that have to be compiled and referenced for every property you have, this makes the code very verbose and very long.  Some people have solved this issue with __call which is called every time you call a function that doesn't exist.  This usually looks like:

class whatever{
  1.   protected $stuff;
  2.   protected $whatever;
  3.   public function __call($name, $params)
  4. }

With some logic you can easily have the function  check for get/set at the beginning of the method name; it works but it's slow and it means that IDE's won't detect the setters/getters  and magic is generally not the best thing.  The even worse case of this is people use __get and __set to overwrite everything, but it does work on every protected/public property and it's an easy way to centralize getters and setters.  This leads us to our last idea, which I personally think is the best way to handle the situation.

My Solution

Obviously we want the ability to overwrite the way things are set, we also need consistency so that we're backwards compatible and the developers don't get confused by what's set via setter and what's set via direct property access, ultimately we don't want to write a bunch of functions just to set and get the values of our properties, it's kinda silly actually, thinking of all those function calls and completely discarding PHP's Property Setting also seems a little foolish.  Anyway, ultimately I came up with the following solution and it works really well for me and the people I work with.

public function __set ($key, $value)
  1. {
  2.   //check if a accessor function exists
  3.   $accessor = 'set'.ucfirst($key);
  4.   if (method_exists($this, $accessor))
  5.   {
  6.     return $this->$accessor($value);
  7.   }
  8. }
  9. public function __get ($key)
  10. {
  11.   $accessor = 'get'.ucfirst($key);
  12.   if (method_exists($this, $accessor))
  13.   {
  14.     return $this->$accessor();
  15.   }
  16. }

With this code in our Model Abstract we are able to call everything via the default method of setting properties i.e.

  1. $object->property = $value;

Most properties would then be marked public, with properties meant to be accessed in this way being set to protected and having set/get functions written for them (that are then marked protected to keep the api clean and to keep interaction sane.)  There is one obvious glaring downside to this though, this does not work with IDE auto-completion, and boy do I wish it did, but out of all things to sacrificed that's pretty minimal.  Also I should mention that the above code does not do any error setting which has been omitted in my example.

Conclusion

There are many ways you can skin this metaphorical cat, however, they each have trade-offs.  Ultimately I went with the methodology that made the most sense to me and that passed our architectural standards (consistency) but you may have a different use case and that's fine.

Filed under: PHP 9 Comments
 « Newer Entries  Older Entries »

Pages

My Tweets

Blogroll