screaming at my screen http://screamingatmyscreen.com/ updates for screaming at my screen - the private domain of Timo Zimmermann en-en Timo Zimmermann Mon, 23 Jan 2017 19:19:04 +0200 Static site generator burnout http://screamingatmyscreen.com/2017/1/static-site-generator-burnout/ http://screamingatmyscreen.com/2017/1/static-site-generator-burnout/ <p>I think by now it is not a secret anymore that I am a strong advocate of static site generators. Especially combined with some CDN making all your security and scalability concerns go away. When asked which one I recommend I usually throw out the two most used ones, <a href="https://jekyllrb.com">Jekyll</a> and <a href="https://gohugo.io">Hugo</a> and also sneak in my own, <a href="https://github.com/fallenhitokiri/drupan">drupan</a>, with the disclaimer that it is opinionated, but still proved to work quite well for different projects. Last year I did not really blog much, but I wrote a few posts. I did not really work that much on drupan, but there are new commits and a 2.4 release pending. What happened?</p> <!--MORE--> <p>There are several reasons, not getting much work done was basically a result of a nearly 5 month crunch time at the beginning of the year followed up with even more stuff to do. I simply had to recuperate, gather some strength and inspiration, take a bit time off and code less. But during the whole time one of the things I planned to do first, once I am back in the game, was taking care of my blog.</p> <h2>Editing is a pain - I miss a CMS</h2> <p>I think by now we all know the advantages of static site generators, writing in markdown, having everything in version control,... Count me in on that. But writing markdown and writing blog posts are two different things. Blog posts have links, images, maybe a video? Manually copying around file names and URLs, hoping you got it right till you generate the site is annoying. Manually managing your files is even more annoying.</p> <p>I simply miss a proper CMS. I was certain I will fix this with Sakebowl, but I am not that sure anymore. Having a flexible CMS that plays nicely with a static site generator is certainly possible. There are a few out there, some of which barely made it out of toy stage and some are actually usable, but far behind of a modern CMS.</p> <p>This is a solvable problem, it is just not properly solved yet. This is also one of the reasons why I did not publish a lot last year.</p> <h3>Multi-user workflow</h3> <p>Do not get me started on this mess. Write a file, send it to someone to review and edit, get it back, replace it, read it again to make sure the edits are correct and hopefully publish your article.</p> <p>There are a few workarounds like keeping your whole site in a version control system and using a hosted service which allows editing files. This partly solves the problem and is not the worst idea. But it is also far from comfortable.</p> <p>It also messes up your workflow to a certain degree. Right now I write most of my articles in Ulysses. After I am done I have to export them to a markdown file, drop to the command line, commit and push, send the link or review request to my fiancee, pull and build. Sure, it is doable, but to me it still sucks. If I would tell myself 10 years ago that at some point I will consider this an unacceptable workflow I am sure I would have declared my future self crazy.</p> <p>Purely working in some online VCS hosting platform is also not really an option. Forcing people out of the applications they started using for some reason is, most of the time, a fight you will not win. Especially when it comes down to something where personal preferences are important, like an editor.</p> <h2>CDNs aka “love hate relationship”</h2> <p>Content delivery networks are, at least in my opinion, one of the best things that ever happened. Having files across the globe, highly available, served as fast as most consumer Internet connections allow for a stupidly low price? Sure, sign me up! And thanks to the fact that we are living in 2017 you can get SSL for free! Even better. How could anyone complain about this?! Well, believe me, I can.</p> <p>So here is what usually happens: I write a blog post, get the editing mess done and publish it. But wait, it is not really published yet, it is only uploaded to S3. The Cloudfront invalidation will take five to ten minutes before it is properly published to all my readers. Sure, I could lower the TTL and skip invalidation requests, but that still means sitting around for some time. Or I could make it so low, that most likely every of the 1000 requests from users a day result in an cache miss making the request slower. For some reason I get a lot of bots hitting my site, but not distributed enough to keep the cache warm.</p> <p>Now we could argue that this is kind of acceptable when you publish something. It does not happen that often, does it? But what about edits? When publishing a post it is possible that it is submitted to HackerNews or Reddit. Want to add a link? No problem, but readers will have to wait for the TTL, most likely resulting in some who would be interested missing the links or for the invalidation request to finish, most likely a lot worse.</p> <p>This does not mean hosting your content on a CDN is a bad idea, it simply means that sometimes I want to update something in real time.</p> <h2>New features</h2> <p>There is a certain set of new features I want to add to my blog. A few of them will be a matter of minutes, like adding a new category for short notes I use to post more frequently instead of splitting text on Twitter for example. But there are things, even with a proper CMS backend, which are somewhere between hard to achieve or greatly increase the backend complexity.</p> <h3>Subscribe to blog</h3> <p>I want my readers to be able to subscribe via email. Sounds simple, doesn’t it? If you have a purely static site the best option will most likely be using a third party service like mailchimp and manually sending out a mail or somehow integrating it as plugin in your static site generator. Since the URL for your content is known before you publish the site, even if your index and archive is not yet up to date thanks to the CDN, you can trigger a mail pointing directly to the post.</p> <p>Of course, this would require the use of client side JavaScript. If this is acceptable in 2017 or not is something everyone has to decide for themselves and the answer is most likely tied to the target audience. One thing that is often ignored is that this is a third party you give your readers data to.</p> <h3>Post via email</h3> <p>Fancy, isn’t it? I want to sit on a beach in San Francisco - hey, I am allowed to have a weekend, even on a work related trip! - and post a picture. Partly to annoy my friends back at home suffering through 8°F days or to inform others that I am currently in SF, which automatically means I am up for a coffee or beer. Don’t ask why, but this sometimes works better than sending a tweet or email.</p> <p>Sure, I could login to a web interface, if I had one, and use this to post. This would even be acceptable, but sending an email is faster. Also I like email. It is one of the few things that never messed up badly during the last 20 years.</p> <p>Actually posting from anywhere, even if it would involve a web interface, would already be a big step into the right direction.</p> <h3>Queues, workers, complexity</h3> <p>Drupan is written in Python. And Sakebowl, the backend, is partly written - as in started but not finished - in Python and Django. Adding new features nearly always requires having a queue, even as simple as Redis, and having workers running doing the heavy lifting. Simple enough, isn’t it? Especially because those are things I am dealing with on a daily basis for over 12 years by now.</p> <p>But something in me is telling me it is not worth it. Having all those different things running, making sure they are available, come up on restarts, handling errors - it is some complexity I am not sure I am willing to maintain in my spare time only to publish a few articles.</p> <h2>Alternatives</h2> <p>There are currently no alternatives I would be satisfied with. I will never move my content to a third party platform like Medium. I will not start messing around with some stale Node.js abomination that consumed an insane amount of crowd funding money for no apparent reason. But I am also not sure Sakebowl will be the right call.</p> <p>Currently I am considering moving from a static site generator to a more mainstream CMS or blogging software. I am not too worried about uptime to be honest. Nearly all hosting providers I have dealt with during the last 5 or 6 years rarely have any downtime and if they do it is a matter of minutes. I actually had more downtime on AWS (admittingly not S3 or CF!) in 2014 if I recall correctly than on my Hetzner vserver. Sure, different beast, but you get the point.</p> <p>I am also not too worried about content being linked on some popular site resulting in a spike in requests. Having the site or page cached in memory should not be hard for any serious blogging platform. And it will most likely be “good enough”.</p> <p>But I still have this point somewhere in the back of my mind. A blog going down because it makes it to the frontpage of HackerNews is just lame. It would still possible to put a CDN in front of whatever, so this should not turn into a problem, but this also would not be much of an improvement to the current setup.</p> <p>Security is a tough cookie. I do not believe any system can beat the current S3 + CloudFront setup. But at the same time I believe it is possible to get a system secure enough that, while not directly targeted, it will survive the big, bad Internet. If directly targeted, well, it is most likely game over. If this turns out to be a major problem it is something I cannot predict.</p> <p>I would prefer having a simple setup. Installing an interpreter, a database, a key value store, a webserver, messing with some obscure startup script to get application servers and workers running is something I would love to avoid doing in my free time.</p> <h2>Are static site generators a bad idea?</h2> <p>Sure, that would make a great headline and most likely guarantee a heated discussion, but sorry to disappoint you. They are as good, or bad, as they always were. I am simply looking for features which are not that easily realisable using a static site generator and which are maybe also not that well realised with an backend for one.</p> <p>I believe static site generators are definitely the right choice for anything that is not updated frequently and has a technical editor. You can even make it simple enough to make copy changes - GitHub + some CI and you are good. Not that comfortable, maybe a small fight against existing tools, but you could manage to get away with it. Agencies maintaining websites for customers? Definitely! Chances are pretty low that your friendly doctor needs any dynamic elements on the website, at least in most parts of the world. Marketing site for a SaaS business? Yep. Decoupling your marketing site from your actual app is not the worst idea.</p> <p>I still love drupan and I am actively working on it. But for the things I want it seems to be a bad fit for it - this is actually harder to admit than it should be. I am currently not sure what the correct solution will be, but I am actively working on it.</p> Mon, 23 Jan 2017 18:39:00 +0200 Surviving Crunch Time http://screamingatmyscreen.com/2016/7/surviving-crunch-time/ http://screamingatmyscreen.com/2016/7/surviving-crunch-time/ <p>For the first 4 months this year I was in a constant crunch mode. At FlightCar we usually tried to avoid this, but we had to ship a redesign of the website, a redesign of the iOS app and finally release a customer app on Android. As for most other seasoned developers this is not the first time I experienced such a time and it will likely not be the last. Over the years I developed quite a few strategies to handle crunch time (and stay sane and productive at the same time) I want to share with you today. <!--MORE--></p> <p>The best case, of course, is to avoid crunch time. Some companies, especially Start Ups claim that this is not possible and that you have to be in a constant crunch. Here is the secret they do not notice most of the time: Playing table soccer does not count as work, no matter how often you try to tell yourself you are working for 25 hours a day while you are actually only shifting the location of your free time. Browsing HackerNews and reddit mostly also does not count as work, sorry.</p> <p>If you still find yourself in a constant crunch one of those two things most likely happened:</p> <ol> <li>You have no idea how to create a proper roadmap</li> <li>You have unrealistic expectations</li> </ol> <p>It usually boils down to one of those two options. One thing you have to realise is that you’re either making sure your developers burn out and you have to hire new ones every three to six months – or you are not actually in a crunch but decided that your free time should be spent in the office doing everything but work.</p> <p>As I already admitted crunch time can happen and there are various, legit reason why it happens. And most of the time it is something that will decide the future of the company. Now if it happens the trick is to make sure you, the team and the companies actually survive crunch time without going crazy, burning out or setting tables on fire.</p> <h2>Daily Routine - Stay Healthy</h2> <p>Even if most of your day is spent working, there are a few things I would strongly suggest doing on a regular basis, first to stay healthy, second to refresh your body and mind.</p> <ol> <li><strong>Exercise</strong> - even if it is only a 10-15 minutes walk, do something that forces your body to move and try to not think about work.</li> <li><strong>Sleep</strong> - no, not with your nose leaning against your screen. In a bed. For more than 5 hours.</li> <li><strong>Eat</strong> - a proper diet, not pizza and Jolt Cola mixed with energy drinks and ibuprofen.</li> </ol> <p>The exercise part can be a bit controversial for some people. I will not try to look up all the studies that actually explain how important this is since I am not in a position to actually verify them, simply take it as a suggestion. It helps me a lot to stick to my daily exercise routine, give it a shot!</p> <h2>Your Team</h2> <p>A project which decides the future of the company also means that during crunch time a lot of people will have an eye on the product and regularly check if the team is on track to get it done. After some time in the industry you will get used to C-level executives looking over your shoulder when you work on something important - and they will remind you how important it is. In itself this is not a bad thing, it only shows that they care, which is actually awesome! Far better than the opposite when they simply stopped caring about the product.</p> <p>There will sometimes be people on your team who are not used to management having such a close eye on what they do, the expectations to get twice the work done in half the time or working on something that could kill the company if something goes wrong. Keep an eye out for those people and try to help them as much as possible with advice and guidance. This should actually be always the case, but someone being a bit stressed during a regular 9 to 5 day is far less likely to go insane and it is way easier to counter than someone not sleeping for 5 days straight because the only thing they got in their head is “if it fails, everything is over”.</p> <p>While you usually cannot downplay the importance of a project, you can set the expectations straight that not getting everything 100% right in time is most likely not as bad as it is suggested. The fine line between motivating a team and putting so much pressure on them that they break is hard to hit. When in doubt try to not get too close to it.</p> <h2>Manage Expectations</h2> <p>You will usually have one big goal at the end of crunch time. Maybe it is a redesign, maybe it is a new feature, maybe it is a new application. But the goal will be defined fairly broad and a lot of smaller components are needed to make it happen. Not all of them are necessary to deliver a great product or a stripped down MVP and not all of them provide the same value to the customer.</p> <p>It is important to start managing expectations early on. Make sure you have all components on a list ordered by priority. Does your admin interface have to be redesigned as well and launched at the same time as the marketing site? Most likely not. Would it be great if your iOS and Android app have feature parity? Sure, but if the app is only supporting your business and is not the core value, it could be sufficient to focus on the core features which are most important for the customer.</p> <p>While product, management and all the people involved can tell you what they ultimately want, only you can tell them if this is realistic, which tradeoffs could help to make it happen and how fast after the expected deadline you can deliver the missing pieces. Start this conversation early, best before the actual crunch time starts and make sure everyone knows and agrees.</p> <h2>Shortcuts And Cleaning Up</h2> <p>“We are going to write the most beautiful, well tested, stable code the world has ever seen” - no one ever during crunch time.</p> <p>You will be taking shortcuts. No matter how good your intentions are. And the shortcuts will be shorter and more ugly than the ones you are usually willing to accept. This is okay, crunch time is not about writing the best code in existence. But, no matter what shortcuts you take, it is important that the product is working as expected. Shipping something broken never helped anyone, and shipping something broken in time is in my opinion worse than not shipping at all.</p> <p>What I strongly suggest is planning time after crunch time to clean up, refactor and make sure your working code is stable and maintainable. Leave some comments in there to identify the parts where you willingly took shortcuts. While most people have the intention to do this, it does not always happen. Making sure this actually does happen is part of the management responsibility for crunch time, the same as setting expectations properly. If you miss this, you will end up with a system that is holding together for now but blows up in a few weeks or months. That this will be required should be communicated to all relevant people before crunch time starts and you should make sure they agree to give you the time. While this is no guarantee, it increases the likelihood to happen.</p> <h2>Final Words</h2> <p>This surely sounds pretty easy and straight forward. Sadly it will not be that way. People will be stressed and as you probably know it is not always easy to work with stressed people. If you got a partner you should make sure they understand why this is so important and if you are lucky they are understanding. When it is over make sure to compensate for the lost time of your life. Always remember that your health is the most valuable thing you possess. Crunch time sucks, but you cannot always avoid it, try to survive the best possible way.</p> Fri, 22 Jul 2016 19:00:00 +0200 The Apple Watch From A Watch Lovers Perspective http://screamingatmyscreen.com/2016/4/the-apple-watch-from-a-watch-lovers-perspective/ http://screamingatmyscreen.com/2016/4/the-apple-watch-from-a-watch-lovers-perspective/ <p>So there is this thing were @revenant333 and I watch the Apple Keynote and after the keynote is over we send each other a quick shopping list. When the Apple Watch was released the reactions were quite different - he had one on his list, I did not see the point in it. I like mechanical watches and I did not really see the point in having another display telling me what my phone already shows. My take on the Apple Watch was pretty straight forward - "buy one if you need it for work". Now I got an Apple Watch and I have to admit I was a bit wrong about the usefulness of it. <!--MORE--></p> <p>When something new is released I usually try to see the use cases in it before making up my mind if I want it. But for the Apple Watch it was a bit different. I already have a watch. A really nice one. I appreciate the work and precision that is needed to build a "real" watch. The same thing cannot be said for a small display at my wrist. It is just that - a display with basic input functionality. It is not a watch, no matter what you name it. I could not imagine trading a fine piece of craftsmanship for another display.</p> <p>Fast forward a few months: I needed to get an Apple Watch for a project. While I still could not see me wearing it, I decided to give it a try for a few weeks. Without hands on experience I do not believe that you would be able to build an app that actually feels right, is usable and provides real value. So with a tear in my eye I put it on. I got the cheapest model - it feels surprisingly okays. I still prefer steel or leather, but even the plastic band is not as bad as I imagined.</p> <h2>The stupid display</h2> <p>Surprisingly I did not spend the next few hours playing with it. My day continued as usual and I just started using it. With the vibration I knew exactly when I had a upcoming meeting, when Jean wanted something or when a mail from someone on my VIP list came in. This is one of the biggest selling points for me. When I am in a meeting I usually have all devices silenced and most of the time my MacBook is closed. If I need to take notes I do it in the most primitive way - pen and paper. This works really well for me, no distractions, easily to focus on the actual meeting and nothing between me and the people I am talking to.</p> <p>Usually I do not wear my watch at home. I am, most of the time, in front of my computer, so I got notifications, the current time and my appointments in the top right of my screen. But since I needed to figure out what works on the watch and what not I kept it on my wrist. I started putting my system in DND mode and started looking at the watch when a notification came in. I get way less notifications on my watch and if I get one, I know it is important enough to look at it.</p> <p>Sometimes it is quite handy to be able to take a call with your watch. Especially when your phone is sitting on your desk and you are two rooms away making sure your cat does not vomit on the carpet. This could surely be solved in other ways, but quickly tapping the accept button to tell your fiancee you hate the cat is really comfortable.</p> <h2>Traveling with the Apple Watch</h2> <p>Standing at the airport, waiting for TSA to fondle me it is easy to take a quick look at an incoming message or an email to figure out if it is urgent enough to pull out the phone and answer or if it can wait. This is quite handy when you actually expect an important message you quickly have to react to coming in.</p> <p>One of the things I tried while being in Budapest for DjangoCon.eu was navigating with the watch while walking from my AirBNB to the market to get something to eat. I have to admit that I had a really hard time getting into the right street - "turn left in 20m" is not helpful enough for me compared to actually seeing the street and directions on an actual map. But after getting used to it and starting to look closely at the street signs it got easier - not good, but acceptable and it is nicer to just look at your watch than walking through the streets looking at your phone.</p> <p>One thing I found quite valuable is sports band while working with my MacBook on a plane. I would normally take off my watch to not scratch the MacBook or watch while resting my wrist on it. But with the plastic band I can keep the watch on and just use my MacBook without risking scratches. The pin keeping the band closed is in a position that is far enough away from the MacBook and therefore the only risk for scratches is minimised to an acceptable factor.</p> <h2>Apple Watch Sport vs Apple Watch</h2> <p>The primary reason why I got the Sport was the price. It is a development device and there is no difference but the case and band, so there was no point in spending more on it than necessary. But if I would consider wearing the watch even without doing development which one would I get? Most likely the Sport again.</p> <p>The Sport feels well build, I really like the matte finish and the band is perfect for travel. Considering that, other than a real watch, you are not planning to pass it on to your son or son in law at one point, but replace it every 2 to 3 years the lower price tag is also nice.</p> <p>One thing to keep in mind is that neither the Watch nor the Watch Sport actually look like something you would usually wear with a proper suit, at least when meeting with more conservative people. Thinking back a few years when I was primarily working with people from the finance sector the Watch would have caused some eyebrows to be raised. For your day to day life, also while wearing a suit, both look the same on your wrist. So if you prefer the Watch or the Watch Sport really comes down to personal preference and style.</p> <p>From what I have heard the Sport could be a bit more forgiving when treated badly. I actually managed to pull off my belt while going through TSA and the belt buckle flipped against the watch and gave it a small nick. So I cannot really confirm that, but I was surprised how small and invisible it is if you do not know what to look for.</p> <h2>Apps, apps, apps</h2> <p>I have to admit the state of apps is really bad. I use the standard apps a lot, but most third party apps are just bad. And I mean really bad. You noticed that most companies most likely just shipped an app to be hip or to be on the good side with Apple.</p> <p>I would start ranting about Twitters decision to display my timeline and their trending tweets, something I never used or cared about, but not showing me mentions or direct messages. But let us be honest - Twitter plainly sucks at building apps on literally every platform in existence.</p> <p>Other apps could display relevant information like a driver and license plate who is about to pick you up or the ETA - but you see a map.</p> <p>There are too many things that are not well thought out and this is exactly the reason why I started wearing and using the Watch before actually starting to develop for it. Most of my critique comes from apps that look like no developer ever actually bothered to wear or use an Apple Watch.</p> <p>Input is surprisingly easy, even with slightly bigger fingers. When starting an app I sometimes missed my actual target in the beginning but I got a hang of it after a few hours.</p> <h2>Fitness</h2> <p>I never was a big fan of too much tech being involved in my exercise and when practicing martial arts I cannot wear tech anyway. But going for a run or doing weight training, especially with the sport band, it is easy to get used to it and you get some basic information about your training that can provide value. One thing the watch allowed me to do is turn of my hourly alarm reminding me to get up to do some push ups and squats. The watch will take care of it, sometimes in an bit annoying way. I still did not figure out how I cannot reach my standing goal while walking for 6 hours through Budapest.</p> <p>I have heard from quite a few people (some who I did never expect to buy into it) to actually move more with the watch on their wrist. Especially because Apple did an amazing job at gasification, it looks like once you got your first full circle you want to keep it up and make it a streak. </p> <h2>Will I continue to wear it?</h2> <p>I do not like to admit it but I got used to the Apple Watch. While still preferring my "real" watch when going out, I will likely go with the Apple Watch for my day to day activities. When out with friends I do not want to be reachable for anyone. I already got an activity and I do not need digital distractions. I know, uncool and old fashioned, but I do not see them often and when I do, I prefer to actually spend time with them than answering mentions on Twitter.</p> <p>One thing I need is a new band. The coating of the sport band started to peel off, leaving transparent flakes on my wrist. I am not sure if I will go for another sport band of if I can find something made of leather, cloth or caoutchouc with the same closing mechanism which would make it safe to use with an MacBook.</p> <p>One thing I would be interested in would be the Apple Watch in the format of an wrist band. That could be the sweet spot for me. A "real" watch on my left wrist, my stupid display showing notifications on my right. Well integrated, basic interaction capabilities. This would not feel as wrong was wearing two watches. I say basic interaction because let us be honest: no on draws a fish to ask someone to go out for sushi and the answers you can send to a message are most of the time too limited - just as Jean thought when I only answered her questions with pre-defined responses while listening to talks.</p> <p>If you are a traditional watch lover you might have the same problem I do - the Apple Watch does not fit into your world view of what a watch is. And that is fine - we are talking about a new device category that would force us to abandon our beloved watches, one of the few pieces of jewellery, and for some men a symbol of status, we can wear in an socially accepted way. But that is something people thought too when the watch moved from the pocket to the wrist. Going against socially accepted ways is not always a bad thing. And in the long run it provides so much comfort, that classic watches will slowly diminish. Even classic manufactures started going for the digital trend. If you want to give it a try the entry price for the Sport is more than acceptable, especially considering the price of the watch you could currently be wearing on your wrist.</p> Wed, 20 Apr 2016 19:59:00 +0200 The sad state of JavaScript markdown editors http://screamingatmyscreen.com/2015/12/the-sad-state-of-javascript-markdown-editors/ http://screamingatmyscreen.com/2015/12/the-sad-state-of-javascript-markdown-editors/ <p>One of the essential parts of <a href="http://screamingatmyscreen.com/2015/12/drupan-2-2-0-the-panda-gets-a-bowl-of-sake/">Sakebowl</a> will be the editor. Maybe even the most essential one - in the end it is a content management system, so you have to enter and edit content. I was planning to stick with markdown. It is fast to write, it has a clear syntax and everyone can pick it up in a matter of minutes. But trying to make markdown editing usable in a browser slowly leads me away from this idea. <!--MORE--></p> <p>Since I want to get a prototype done I was looking for existing JavaScript markdown editors. There are dozens of them. Some have a split view, rendering your markdown live and showing you how your content will look like, some have a preview mode, some only have a toolbar with quick access to the most common formatting options. But they are all unbelievable bad at different things.</p> <p>My biggest complaint is that nearly all of them mess up the textarea you are writing in, which means no auto correct, sometimes no default copy &amp; past functionality in iOS or not being able to scroll on a mobile device. Now you can say what you want about <a href="https://ghost.org">Ghost</a>, but there is one thing they definitely got right: the editor.</p> <p><a href="ghost.png"><img src="ghost.png" alt="ghost editor" /></a></p> <p>And I still believe this editor is far from user friendly. It is user friendly if someone knows markdown. But why not just add a few buttons for the basic formatting needs like bold, italic and adding a link or image? Maybe they felt like usability would clutter their design. Or they never intended to have a non-technical user base.</p> <p>Right now it looks like I will have to write an editor. Adding the buttons is easy thanks to markdowns simple syntax. Adding a preview is also no rocket science, there are enough JavaScript library to render markdown. Adding the nice stuff like drag and drop for images or a proper media manager triggered by the preview window gets harder. But I feel like not putting some time into the core component of a CMS would not be the smartest decision.</p> <p>I will still continue to look into possibilities and other options than writing it myself, but currently I think I am out of luck with existing solutions. Maybe if I manage to build a decent implementation I will extract the component and release it as a separate project, but that will surely take some time.</p> Wed, 23 Dec 2015 21:29:00 +0200 drupan RAWR - the next steps http://screamingatmyscreen.com/2015/12/drupan-rawr-the-next-steps/ http://screamingatmyscreen.com/2015/12/drupan-rawr-the-next-steps/ <p>I am not sure if Drupan is getting more and more users or the existing users want more features and report more bugs. But one thing is pretty clear to me: While my little drunken panda is still my favorite pet project, I slowly have to consider what the user base wants to see. Some of the most recent changes were primarily introduced to support <a href="http://screamingatmyscreen.com/2015/12/drupan-2-2-0-the-panda-gets-a-bowl-of-sake/">Sakebowl</a>, but they also allow me to implement new features way easier and without increasing the number of dependencies of the default installation. <!--MORE--></p> <p>Drupan supported plugins from the first version. But since we are living in a Python world, making them part of the main distribution meant that you would have had to install markdown, textile and whatever markup language would have been included libraries while installing drupan. The other option would have been not making the required libraries part of the default installation and throwing weird errors while using drupan. In my opinion both scenarios are user hostile and not something I wanted to implement.</p> <h2>Plugins, plugins, plugins!</h2> <p>With the next minor release I will introduce a new way to load plugins which will allow you to pip install new plugins. So if you want to write your posts using textile the only two things you will have to do is running <code>pip install drupan-textile</code> and adding textile to your plugin list.</p> <p>There are a few things I still have to think about. Does it make sense to support requiring other plugins or should plugins be forced to be self contained? Should a plugin be able to list other plugins that make no sense when used together - markdown and textile, for example? Should I add a possibility to put plugins in a random location like your site directory - basically what <a href="http://jekyllrb.com/docs/plugins/">jekyll</a> does?</p> <p>There are several plugins that I will ship near the release of drupan 2.3:</p> <ul> <li>searching the whole site using JavaScript</li> <li>textile support</li> <li>restructure text support</li> <li>syntax highlighting using <a href="http://pygments.org">pygments</a></li> </ul> <p>It is possible that I will start with pip installable plugins and only introduce site specific plugins later.</p> <h2>Templates, templates, templates!</h2> <p>Starting a new site is kind of okay right now. At least if you ask me. If you ask some of the designers I talked to I messed up big time. "Git clone what?! I just want a blog skeleton!"</p> <p>Templates will likely go the same route as plugins. You will be able to <code>pip install</code> them. In the first iteration it will work like this:</p> <ul> <li><code>pip install drupan drupan-theme-OMG-IT-IS-SO-BEAUTIFUL</code></li> <li><code>drupan --new siteName</code></li> </ul> <p>That is it. No third step. I will get into the details in a moment. This does not mean you will not be able to modify the template anymore. You will be able to run <code>drupan --clone-template ~/mySite/template</code> which will copy all template files so you can edit those stupid stock photos and replace them with pictures of your kitty.</p> <p>To make sure we got some nice templates my fiancee will be porting some stock templates over to drupan, so there will be a nice blog template, some marketing site, a landing page and maybe a photo portfolio.</p> <h2>CLI, cli, cli!</h2> <p>It is time to introduce a command line interface to make drupan easier to use. This will not replace the the existing functionality but add to it. Configuration files will be stored in <code>~/.drupan/</code> for example, they will be automatically generated by <code>drupan --new</code> and you can generate a site with <code>drupan siteName</code>. Another nice side effect is that the only thing you will need to see in your file system is your content directory and maybe the template directory if you insist on changing those awesome, state of the art, nearly artistic, stock templates.</p> <p>The functionality for now will be related to creating new sites and generating and deploying existing ones. I am not sure if there should be more functionality like managing posts. Every time I hear people talking about <a href="http://octopress.org">Octopress</a> it sounds like they really love features like draft, publish and so on. So maybe it is not the worst idea to bring some of those features to drupan.</p> <h2>Next Steps</h2> <p>I started working on the new plugin system and will focus on the template system next. Somewhen next weekend you will see a new <a href="https://github.com/fallenhitokiri/drupan">2.3 branch on GitHub</a>. If you want to use those features before they are officially released feel free to do so. My plan is to keep the 2.3 branch stable and do the feature development in other branches. Since the features are pretty big I want to get them in the hands of people as soon as possible. If you are planning to write a plugin take a look at one of the <a href="https://github.com/fallenhitokiri/drupan/tree/master/drupan/plugins">existing plugins</a>, <a href="https://github.com/fallenhitokiri/drupan/blob/master/drupan/plugins/markdown.py">markdown</a> is pretty small and should give you a good idea how plugins work.</p> <p>I am considering making a drupan organization on GitHub to keep all plugins, templates and drupan itself together in one spot. I feel like having dozens of repositories in my private account does not increase the discoverability. On the other hand this could be an overkill. If you got any experience or input on this step please let me know!</p> Wed, 09 Dec 2015 18:59:00 +0200