|
|
| Line 64: |
Line 64: |
| | --[[User:JaroslavTulach|JaroslavTulach]] 07:40, 27 September 2012 (UTC) | | --[[User:JaroslavTulach|JaroslavTulach]] 07:40, 27 September 2012 (UTC) |
| | | | |
| - | ==== Is [[C]] Better than [[C++]]? [[Scala]] Rules! ====
| + | [[OlderBlogPosts]] |
| | | | |
| - | Recently I've noticed an interesting [[trait|article]] describing why C is more effective than C++ and in general most of OOP languages. The article is well written and for a while I was nodding in an agreement. The claim that by using OOP and insisting on encapsulation one cannot implement linked list as effectively as in C is a very good one!
| |
| - |
| |
| - | However later I realized that the take on OOP is really targeted to OOP languages of the past. In modern languages, like [[Scala]], one can keep encapsulation and still be as effective as the old plain good C.
| |
| - |
| |
| - | All you need is proper orchestration between the ''List'' container and its [[trait|element]]s. [[Scala]] will then type-safely handle the rest for you!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 05:11, 3 September 2012 (UTC)
| |
| - |
| |
| - | ==== Why I Became an API Designer? ====
| |
| - |
| |
| - | {{:API Designer}}
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 08:17, 30 August 2012 (UTC)
| |
| - |
| |
| - | ==== Is Invisible Method Signature Part of API? ====
| |
| - |
| |
| - | {{:InvisibleAbstractMethod}}
| |
| - |
| |
| - | --[[User:Apidesign|Apidesign]] 12:13, 20 March 2012 (UTC)
| |
| - |
| |
| - | ==== API Design is JavaOne Rock Star ====
| |
| - |
| |
| - | My presentation about [[ParadoxesVideo|API Design Paradoxes]] has been rewarded as one of the more interesting ones during [[JavaOne2011]]. There is no video at the [http://www.oracle.com/javaone/quick-links/rock-star/2011-rock-stars-1453436.html JavaOne rock star page], but as I keep repeating the presentation again and again with almost the same content, you can view the [[ParadoxesVideo|Linz 2009]] version or [[Ostrava|Ostrava's 2011]] translation to Czech.
| |
| - |
| |
| - | It was fun to talk about [[Paradoxes]], but I guess it is time to come up with something new. I'll try to resubmit my talk about [[AnnotationProcessor]]s next year. Hopefully the just gained Rock Star status will give that talk few plus points and raise its chances to be accepted.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 08:58, 20 January 2012 (UTC)
| |
| - |
| |
| - | ==== Beware of Friends! They'll Change You! ====
| |
| - |
| |
| - | In case you are doing something for [[FriendDependencies|friends only]] (as many of ''facebookers'' do), you are in a great danger. Blindly increasing list of your [[FriendDependencies|friends]] is not for free. Because (as soon as you change list of your [[FriendDependencies|friends]]) you change yourself, you will immediatelly become ''different'' from outside.
| |
| - |
| |
| - | This, in an [[API]] terminology means, you need to produce new version of '''yourself'''. Thus, when you publicaly state you have a new [[FriendDependencies|friends]], version yourself! Read about [[FriendDependencies]] to understand why!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 15:20, 19 September 2011 (UTC)
| |
| - |
| |
| - | ==== [[JDK]]7 Breaks [[JUnit]] Tests ====
| |
| - |
| |
| - | Without the intent to blame JDK7 for being finally available, I have a [[OrderOfElements|concern]] to [[OrderOfElements|share]]. After switching the NetBeans test runs to use JDK7, most of the test suites [[OrderOfElements|started to fail]] randomly!
| |
| - |
| |
| - | In case you are considering to switch to JDK7 and you have existing JUnit tests, consider including the time for [[OrderOfElements|stabilization of the tests]] into your migration plan.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 12:33, 22 August 2011 (UTC)
| |
| - |
| |
| - | ==== [[API]] Designers: Are You Planting Forests or Gardens? ====
| |
| - |
| |
| - | Today I have an unusual chance to talk about gardening (or planting forests) when designing APIs. The key concept to grasp is the ability to [[APIvsSPI|mount]] various types of APIs together. Btw. do you know that there are more [[APIvsSPI|types of APIs]], right? Learning how to [[APIvsSPI|mount]] them together is an important knowledge that will determine whether your [[APIvsSPI|API or SPI]] will turn into a beautiful garden or fall into disorder of unmaintained, dark forest. Visit [[APIvsSPI|today's essay]] to learn how to properly [[APIvsSPI|mount]] [[APIvsSPI|client APIs and provider APIs]] so they can strengthen [[APIvsSPI|each other]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 13:03, 21 March 2011 (UTC)
| |
| - |
| |
| - | ==== Using [[Netbinox]] [[NetbinoxHook|hooks]] ====
| |
| - |
| |
| - | Do you want to use extension [[NetbinoxHook|hooks]] to extend behavior of Netbinox the same way you used to extend Equinox? Before version 1.16.7 this used to be complicated, but as this [[NetbinoxHook|little tutorial]] shows, now [[NetbinoxHook|hooks]] can be registered easier than ever.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 15:49, 29 January 2011 (UTC)
| |
| - |
| |
| - | ==== Beware of Using [[Enum]]s ====
| |
| - |
| |
| - | Have you ever thought that [[enum]] in JDK5 is good idea? Then welcome to the club. I used to think that as well. But it is not, when it comes to API design. Read [[enum|why]] to understand its gotchas.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 22:04, 12 January 2011 (UTC)
| |
| - |
| |
| - | ==== Visualize [[Lookup]] ====
| |
| - |
| |
| - | There is a [http://dev.imagejdev.org/gbh/lookup/map.htm very nice visualization] of [[Lookup]] and its family on the [http://dev.imagejdev.org/gbh/lookup/map.htm ImageJ web site]. It is created by MindMap and I find it quite explanatory. In case you ever wanted to sort your thoughts about [[Lookup]], this [http://dev.imagejdev.org/gbh/lookup/map.htm mind map]] is definitelly going to help.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 16:24, 10 January 2011 (UTC)
| |
| - |
| |
| - | ==== Access [[Facebook]] from a Desktop Application ====
| |
| - |
| |
| - | Having trouble to access [[Facebook]] from your desktop application? I know how to help you out of your missery. Read [[facebook|the story]] and source code for my [[Facebook|Feedbook]] desktop application - application that I use to re-publish my blogs from this site to my [[Facebook]] account.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 19:46, 16 November 2010 (UTC)
| |
| - |
| |
| - |
| |
| - | ==== One [[ClassLoader]] to Know Them All! ====
| |
| - |
| |
| - | Modularizing monolithic application into individual pieces has various benefits. For example classes will be well isolated from each other. However there can also be pitfalls. For example classes can be too much isolated from each other and '''Class.forName''' can yield bunch of '''ClassNotFoundException'''s. What you need in such situation is a [[ThreadContextClassLoader|classloader that knows everything]]. Here is a little [[ThreadContextClassLoader|essay]] about problems you can face when building [[ThreadContextClassLoader|it]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 10:35, 9 November 2010 (UTC)
| |
| - |
| |
| - | ==== Removing '''protected''' '''abstract''' Methods is no Longer Source Compatible ====
| |
| - |
| |
| - | Rijk van Haaften [[Errata 6|noticed today]] that removing '''protected''' '''abstract''' methods (which used to be ''source compatible'') is no longer compatible at all. I am adding his comment to [[Errata 6|errata for chapter 6]]. Please find Rijk's observation [[Errata 6|there]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 07:44, 8 October 2010 (UTC)
| |
| - |
| |
| - | ==== [[JDK]]6 [[API]] for [[SQL]] Syntax Completion ====
| |
| - |
| |
| - | Do you know that [[LiveDB#Extending_IDEs|there is]] a standard Java API for extending any IDE with code completion? That you can easily, without writing any IDE plugin show list of SQL tables inside strings? Learn [[LiveDB#Extending_IDEs|more]], try out whether your favorite Java IDE comes with real [[LiveDB#Extending_IDEs|support for Annotation Processors]]. If not, make a switch to the best IDE that [[LiveDB#Extending_IDEs|does that]]!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 18:56, 29 August 2010 (UTC)
| |
| - |
| |
| - | ==== [[LiveDB]]: Make Your Database Schema Part of Your Sources ====
| |
| - |
| |
| - | I really hate when something is defined at two places. Things like that may easily get out of sync and where is the truth then? I am glad that my little [[LiveDB]] experiment shows one more field in [[Java]] where such duplication may no longer be necessary: with [[LiveDB]] you can access schema of your database ''live''. ''Live'' not only during compilation, but also during developement from inside of any good IDE.
| |
| - |
| |
| - | Get the [[LiveDB]] sources to learn more. Watch our [[LiveDB]] screen cast. [[LiveDB|Share]] your thoughts!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 17:17, 30 July 2010 (UTC)
| |
| - |
| |
| - | ==== [[Equinox]] Compatibility Shaking ====
| |
| - |
| |
| - | While trying to upgrade from version 3.5 to 3.5.2 I noticed some [[EquinoxCompatibility]] problems. Why can't an [[upgradability|upgrade]] of a minor version of some library be just a plain drop in replacement? How can someone rely on a library which shakes its behavior like an [[amoeba]]?
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 09:34, 13 July 2010 (UTC)
| |
| - |
| |
| - | ==== [[Equinox]] is not Ready for Modular Environment! ====
| |
| - |
| |
| - | Today I noticed one [[BootstrappingEquinox|bootstrapping problem]] with [[Equinox]] which makes it completely unusable for execution in [[modular system]]s. Rather than fixing it I decided to write (thought) provoking [[BootstrappingEquinox|blog]] about problems [[BootstrappingEquinox]]. I hope it will help everyone understand how [[BootstrappingEquinox|bad the situation]] is and encourage creation of [[BootstrappingEquinox|proper fix]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 08:20, 7 May 2010 (UTC)
| |
| - |
| |
| - | ==== Unbearable Painfulness of Being [[Stateful]] ====
| |
| - |
| |
| - | Do you know the feeling like [[stateful|this]]? Something leaves strong impression inside you. So strong that you want to speak up. Later you calm down. Then you get into similar situation again. This time you want to scream. Then you forget. At least you try. But the nightmare comes back again, and now you can't remain silent.
| |
| - |
| |
| - | This happens to me particularly when using [[stateful|one specific]] NetBeans API. For a while I was just complaining to myself, but then I realized the cause of the problem. The API was properly reviewed (even by me) and looked OK, but as time shows, there is a hidden catch: It is too [[stateful]]! It is easy to write program that compiles against that API. It is much more harder to create a program that also executes without throwing runtime exceptions.
| |
| - |
| |
| - | Have you ever had similar experience? Has it been also because of the API being too [[stateful]]? Compare your experience with [[stateful|mine]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 14:29, 2 May 2010 (UTC)
| |
| - |
| |
| - | ==== The Fastest [[OSGi]] Container ====
| |
| - |
| |
| - | Are you seeking for the world's [[NetbinoxPerformance|fastest OSGi container]]? Then you are on the right blog - since yesterday the OSGi container with fastest start is [[NetbinoxPerformance|provided by NetBeans]]!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 12:15, 2 April 2010 (UTC)
| |
| - |
| |
| - | ==== Introduce Yourself to Your Mirror! ====
| |
| - |
| |
| - | Are you [[protocols|talking]] to yourself when standing in front of a mirror? Are you properly [[protocols|introducing]] yourself to your mirror picture? No!? Well, you should be. Good communication [[protocols]] require people to introduce before the real chat starts.
| |
| - |
| |
| - | To improve your design skills, I suggest you to do it even dealing with a [[protocols|man in the mirror]]!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 03:38, 25 March 2010 (UTC)
| |
| - |
| |
| - | ==== Reach harmony. Play Single-tone! ====
| |
| - |
| |
| - | A step by step cook book for properly using [[Injectable Singleton]]s is now available. In case you ever wanted to expose your ''application state'', the [[Injectable Singleton]]s approach gives you sound, simple, testable and extensible way to do it. I don't expect a massive migration from DI to [[Injectable Singleton]]s, but in some situations this pattern may be handy. If you find [[Injectable Singleton]]s useful, [[Talk:Injectable Singleton|share your experience]] with others.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 20:12, 9 February 2010 (UTC)
| |
| - |
| |
| - |
| |
| - | ==== Overcome Your Fear of Being Single(ton)! ====
| |
| - |
| |
| - | Have you ever felt lonely like a [[singleton]]? I do from time to time. Especially when I get a feeling that I cannot break through and outreach people who I'd like to talk to.
| |
| - |
| |
| - | Surprisingly this often happens when trying to talk to DI community. I cannot enumerate how many times I heard: "This is not DI!" "[[Singleton]]s are wrong!" "Learn to use Spring and then come back!" Looks like I have a problem with DI guys. But that is not true, I like DI, I've (already) learned a lot about it! It is more that some DI proponents seem to have problem with us. It usually go like this: A Joe Developer after being hurt few times by coding without DI, learns about DI, finds it amusing, uses it successfully, things start to make sense. Then, rather then being happy that Joe's own projects are fine, Joe starts to evangelize the right way to code. What is not DI is wrong or at least old fashioned, and deserves a rewrite. It actually does not matter what it is, but if it is not using DI, it has to be bad.
| |
| - |
| |
| - | The problem is that Joe never investigates what the other technology is, never tries to understand whether it is wrong or not. Joe has pre-made answers for everything. Joe's opinion is straighten inside of own community. The fact that the community is rapidly growing ensures Joe that this is the only way to deal with programming. Everyone else needs to convert, or be crucified. The faster, the better. Don't waste time trying to understand the others!
| |
| - |
| |
| - | As a result not many DI fans outreach and give us a chance to speak up. Thus I am very glad that Witold Szczerba did it, and asked very interesting question with a lot of good reference material. As a result I could sort out my own thoughts and create a defense of [[singleton]]s.
| |
| - |
| |
| - | Don't be afraid of [[singleton]]s! They are quite friendly if you know [[singleton|how to use them]]!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 08:26, 25 January 2010 (UTC)
| |
| - |
| |
| - | ==== Tim Boudreau on Lookup ====
| |
| - |
| |
| - | In response to a mailing list question Tim decided to explain [[Lookup#Tim_Boudreau_on_Lookup|everything you ever wanted to know about Lookup but were afraid to ask]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 08:59, 20 January 2010 (UTC)
| |
| - |
| |
| - | ==== Video: Paradoxes of API Design ====
| |
| - |
| |
| - | Do you want to [[Paradoxes of API Design|learn something]] about [[API]] design while watching TV? Then you need to get my show from [[Paradoxes of API Design|Blip TV]]!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 11:28, 12 January 2010 (UTC)
| |
| - |
| |
| - | ==== The Little Manual of API Design ====
| |
| - |
| |
| - | When googling around for new references to my book I found out a [[The Little Manual of API Design|year old PDF]] from Trolltech. {{:The Little Manual of API Design}}.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 13:50, 28 November 2009 (UTC)
| |
| - |
| |
| - | ==== Avoid [[Visitor]]s. Unless you really know them. ====
| |
| - |
| |
| - | [[Visitor]] pattern is one of the well known [[OOP]] patterns. However using it in an [[API]] is dangerous. At least unless you have read [[chapter 18]] of [[TheAPIBook]] or studied my [[visitor|sample code]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 08:59, 24 November 2009 (UTC)
| |
| - |
| |
| - | ==== Podcast: [[AOP]] is not dead. If you know how to use it! ====
| |
| - |
| |
| - | Recently I saw the future of [[AOP]]. I thought one should say goodbye to AspectJ and its clones and get ready for ease of use that makes [[AOP]] wide spread! After few [[Talk:AOP|comments]] I know that it is enough to learn more advanced capabilities of AspectJ. But don't forget to do so, such flavor of [[AOP]] is much better than plain writing of aspects.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 12:56, 21 November 2009 (UTC)
| |
| - |
| |
| - | ==== Screencast: Module System for [[Java]] ====
| |
| - |
| |
| - | [[Module system]] is single, most important missing feature of [[Java]]. It is essential for the vitality of the [[Java]] system to define and agree on shared standard. On shared common ground. Recently me and [[Geertjan]] created a recording where we discuss why it is important to have it. We also demonstrate on the [[NetbinoxTutorial|NetBeans and Mylyn]] synergy how such system would simplify our lives. If you have half an hour, listen to [[Module system|our screencast]] and join us with comments.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 09:07, 27 October 2009 (UTC)
| |
| - |
| |
| - | ==== The End of [[MVC]] as We Know it ====
| |
| - |
| |
| - | Geertjan literally forced me to record a screencast about [[DCI]] with [[Geertjan|him]] today. We did rehearsal over lunch and beer (quite lively and interactive). Then he drag me into the recording room and we did it (less interactive, but more serious and important).
| |
| - |
| |
| - | [[DCI|Join us]] to learn why [[MVC]] days are over and you should switch to a new [[DCI|paradigm ready for the 21st century]]!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 20:52, 22 September 2009 (UTC)
| |
| - |
| |
| - | ==== @Synchronized ====
| |
| - |
| |
| - | {{:Synchronized}}
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 08:51, 7 September 2009 (UTC)
| |
| - |
| |
| - | ==== XML, Schema, SAX. @Annotations! ====
| |
| - |
| |
| - | Some [[Talk:First_Amoeba_Video|say]] that code completion with annotations is not big improvement. XML can have code completion too if we give XML Schema with it. I [[Talk:First_Amoeba_Video|disagree]]! Anyone to comment on [[Talk:First_Amoeba_Video|that]]?
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 10:35, 31 August 2009 (UTC)
| |
| - |
| |
| - | ==== Extend Inextensible! ====
| |
| - |
| |
| - | Interfaces are not extensible. [[ExtendingInterfaces|Learn]] how to extend them!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 11:31, 19 August 2009 (UTC)
| |
| - |
| |
| - | ==== Try to Steal my Object! ====
| |
| - |
| |
| - | Recently my cousin was teasing my mind with a question whether there is a way to make anything [[PrivateJavascript|private in Javascript]]. I may be wrong, but I think there is: Is there anyone who can [[PrivateJavascript|steal and modify]] my internal ''impl'' object?
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 04:35, 5 August 2009 (UTC)
| |
| - |
| |
| - | ==== Plug into Your Compiler! Optimize Your Framework by Generating Compile Time Caches. ====
| |
| - |
| |
| - | Learn how to generate [[CompileTimeCache]]s with a little help of source-only [[annotation]]s and their [[AnnotationProcessor]]s.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 14:08, 25 July 2009 (UTC)
| |
| - |
| |
| - | ==== Victims of Conceptual Surface ====
| |
| - |
| |
| - | Do you know how to eliminate classes with too many dependencies like '''java.beans.Beans'''? You need to [[Modular_Java_SE#Sneaking_Simplicity_In|Sneak in Simplicity]]!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 16:32, 22 June 2009 (UTC)
| |
| - |
| |
| - | ==== Splitting applet and beans via [[CodeInjection]] ====
| |
| - |
| |
| - | I have a [[Modular_Java_SE#Infrastructure|basic infrastructure]] to split the JDK which could be useful in your project as well. Also I managed to successfully [[Modular_Java_SE#java.applet_and_java.beans|split java.beans and java.applet]] packages.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 12:39, 17 June 2009 (UTC)
| |
| - |
| |
| - | ==== Help me modularize JDK ====
| |
| - |
| |
| - | Creating [[Modular_Java_SE|modular JDK]] while keeping compatibility with the existing monolithic one may be tricky. Will you help me find right way to do it?
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 20:14, 14 June 2009 (UTC)
| |
| - |
| |
| - | ==== Everyone is equal. Except [[Privileged API|Power]] Users. ====
| |
| - |
| |
| - | Learn to design [[Privileged API]] suitable for ''power'' users of your library. Don't forget to listen to [[Media:Apitip03-constructor-and-competition.mp3|podcast #3]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 17:01, 25 May 2009 (UTC)
| |
| - |
| |
| - | ==== Double Injection. Loosely Coupled SpringFramework. ====
| |
| - |
| |
| - | I have just finished the [[LookupAndSpring|bridge]] between [[Spring]] and [[Lookup]] (originally written by [[AndreiBadea]]) and prepared a [[LookupAndSpring|demo application]] to demonstrate what it can be [[injection|useful for]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 04:43, 28 April 2009 (UTC)
| |
| - |
| |
| - | ==== Clear Definition of Version ====
| |
| - |
| |
| - | Interfaces are absolutely perfect tool to achieve [[ClearDefinitionOfVersion]]. A curious reader [[Talk:ImplementOnlyInterface|question]] made me write the [[ClearDefinitionOfVersion]] page - many thanks for your [[Talk:ImplementOnlyInterface|talkback]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 19:55, 24 April 2009 (UTC)
| |
| - |
| |
| - |
| |
| - | ==== Lookup is Free! ====
| |
| - |
| |
| - | Time to pickup [[Lookup|cherries]]! Nobody can know what happens to [[NetBeans]] after the [[wikipedia::Sun_Microsystems|Sun]]/[[wikipedia::Oracle_Corporation|Oracle]] acquisition. Better to be ready for everything and save the [[NetBeans]] [[API]] pieces that make sense outside of the project boundaries. One of them is [[Lookup]]. I am proud to announce that [[Lookup]] has new home now: [http://lookup.apidesign.org lookup.apidesign.org]. Welcome the refugee and let me know if there is a way I could improve the library.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 05:54, 21 April 2009 (UTC)
| |
| - |
| |
| - | ==== D2D: Factory instances are more flexible than factory classes ====
| |
| - |
| |
| - | As part of ''Designers To Designers'' section on this website I seem to have a unique chance to introduce [[Talk:Factory|Factory instances are more flexible than factory classes]] article by (yet) unknown designer. Enjoy, [[Talk:Factory|talk back]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 08:40, 18 April 2009 (UTC)
| |
| - |
| |
| - | ==== Can there Be ''Implement Only'' Interface? ====
| |
| - |
| |
| - | Here is my [[ImplementOnlyInterface|answer]] to question that I [[Talk:ClarityOfTypes|got by parren]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 18:20, 12 April 2009 (UTC)
| |
| - |
| |
| - | ==== Application Context in [[Ruby]] ====
| |
| - |
| |
| - | Recently I've noticed a lot of [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution#Ruby_Application_Context|activity]] in the [[Main_Page|apidesign.org wiki]]. Perfect. Inspite it is more posts than I can handle.
| |
| - |
| |
| - | However I am thankful for all your comments and I hope this [[Main_Page|wiki]] can become a place for exchange of ideas between people interested in [[API]] design. For example, Steve Shapero added a note about his will to seek for [[Talk:Blogs:JaroslavTulach:Theory:LanguagesForEvolution#Ruby_Application_Context|Application Context]] implementation in [[Ruby]]. I personally cannot be really useful, as my knowledge of the [[Ruby]] language is quite basic, but maybe some of you will join Steve's effort.
| |
| - |
| |
| - | PS: Let us know how it went. You know, I feel that [[Ruby]]'s duck-typing and [[API]] contracts may not be ''mutually strengthening''...
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 19:30, 11 April 2009 (UTC)
| |
| - |
| |
| - | ==== Get Rid of Multi-Meaning Classes ====
| |
| - |
| |
| - | In the latest [[ClarityOfTypes|example related to modifiers]], I'll explain how to achieve even more [[clarity]] than advocated by [[EliminateFuzzyModifiers]] essay. Today we are going to [[ClarityOfTypes|eliminate multi-meaning classes]]!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 16:42, 1 April 2009 (UTC)
| |
| - |
| |
| - | ==== Eliminate Fuzzy Modifiers! ====
| |
| - |
| |
| - | Time for [[EliminateFuzzyModifiers|new post]] about modifiers. My recent take on [[ClarityOfAccessModifiers|access modifiers]] generated quite a bit of interest. I've received a [[Talk:ClarityOfAccessModifiers|bunch of comments]] and I am thankful for all of them! I've learned about approaches taken by different languages, I've started to think about my future, but more importantly ''Arno Nyhm'' asked me to:
| |
| - |
| |
| - | : please show not only a bad example for the Factorial
| |
| - | : but also a good solution for this implementation.
| |
| - |
| |
| - | At your wish ''Arno''! Enjoy (almost) real world example how to [[EliminateFuzzyModifiers]]! And let me know what [[Talk:EliminateFuzzyModifiers|you think]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 20:50, 27 March 2009 (UTC)
| |
| - |
| |
| - | ==== Time to Fix [[Java]] Access Modifiers! ====
| |
| - |
| |
| - | I have an [[Blogs:JaroslavTulach:Practical Design:FixModifiers|open letter]] to designers of [[Java]] language for [http://openjdk.dev.java.net JDK7]: Can you please make [[Java]] modifiers [[API]]-friendly?
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 22:14, 25 March 2009 (UTC)
| |
| - |
| |
| - | ==== Co-exist in Peace! Accept Alter Ego. ====
| |
| - |
| |
| - | APIs age and from time to time they get into so bad state that they need an [[AlternativeBehaviour|alternative]] reimplementation. At that time one has to face a dilemma: Keep [[BackwardCompatibility]] or break it and improve the [[API]]? As [[AlternativeBehaviour]] page explains there is no contradiction between these two. One can deliver improvements while retaining [[BackwardCompatibility]]. All that is needed to teach the [[API]] to accept its Alter Ego.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 16:56, 16 February 2009 (UTC)
| |
| - |
| |
| - | ==== Beware Exposing Yourself to Public! ====
| |
| - |
| |
| - | Erwin Vervaet asked me to provide an explanatory example:
| |
| - | :I have a question regarding chapter 11, section "Pitfalls of Java Monitors".
| |
| - | :Could you please provide an example illustrating the problem, where
| |
| - | :subclasses interfere with the parent class's monitors?
| |
| - | It took me a while to expose that example, but here finally is my newest page talking about Pitfalls of [[Java Monitor]]s.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 10:15, 12 February 2009 (UTC)
| |
| - |
| |
| - | ==== Try, catch, and don't give up! ====
| |
| - |
| |
| - | When your call to a method generates an exception, what can you do? Print warning and give up? Yes, often. Unless the [[TryCatchRedo]] pattern is in use!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 15:29, 2 February 2009 (UTC)
| |
| - |
| |
| - | ==== Accept Unacceptable! ====
| |
| - |
| |
| - | When you maintain some code and you get a patch that you do not like, what can you do? Is the only option to refuse the change, or is there a better way? Of course, as this was just a rhetorical question, there is better solution: Just create a [[CodeInjection|code slot]]!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 21:31, 10 January 2009 (UTC)
| |
| - |
| |
| - | ==== Singletonize your own Factories! ====
| |
| - |
| |
| - | I am reading my own book and I've just got to page that talks about a pattern called among the NetBeans team [[Singletonizer]]. [[TheAPIBook]] describes it with a small note, but as I think it is very useful, I've just created a dedicated [[Singletonizer|page]] describing it in more detail, giving it more, well deserved, publicity.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 16:29, 25 December 2008 (UTC)
| |
| - |
| |
| - | ==== Wizard is the best [[API]] ====
| |
| - |
| |
| - | There is a nice [[Talk:PropertyFiles|discussion]] provoked by description of my [[PropertyFiles|manifest advantures]]. It reminds me once again how important tools are. As I wrote somewhere in [[TheAPIBook]], I guess it is in [[Keep_Testability_In_Mind|Chapter 9]], one of the best [[API]]s is '''wizard'''. Good wizard can turn any API, regardless how bad, into perfectly shining, beautiful [[Blogs:JaroslavTulach:Theory:DiamondsVsStars|star]]. Good tools make everything easier.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 13:49, 19 December 2008 (UTC)
| |
| - |
| |
| - | ==== Builder vs. Cumulative Factory ====
| |
| - |
| |
| - | Is [[Builder]] better [[APIDesignPatterns|pattern]] than [[CumulativeFactory]]? As Radim and Paulo [[Talk:CumulativeFactory|pointed out]], it might be. However from [[Builder|my point of view]], it is an extension to [[CumulativeFactory|the previous one]]! Read more and [[Builder|help us decide]]...
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 13:02, 15 November 2008 (UTC)
| |
| - |
| |
| - | ==== Cumulative Factory [[APIDesignPatterns|API Design Pattern]] ====
| |
| - |
| |
| - | Dear API writers, let me introduce you to [[APIDesignPatterns:CumulativeFactory|cumulative factory]] [[APIDesignPatterns|API Design Pattern]]. Read [[APIDesignPatterns:CumulativeFactory|more]]...
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 15:38, 9 November 2008 (UTC)
| |
| - |
| |
| - | ==== ''How Many People Have to Die'' leakages ====
| |
| - |
| |
| - | Recently I've been [[LeakingCulturalContext|warned]] that my sidebar in [[Ever_Changing_Targets|Chapter 4]], Ever Changing Targets talks about events that are completely ununderstandable for international readers. That made me write a short essay about [[LeakingCulturalContext|leakages of cultural contexts]] and the similarities with the [[TheAPIBook|API Design]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 05:01, 21 October 2008 (UTC)
| |
| - |
| |
| - | ==== Exceptions in API ====
| |
| - |
| |
| - |
| |
| - | Casper Bang asked following question about [[APIDesignPatterns:Exceptions|exceptions in API]] after reading the [[TheAPIBook]]:
| |
| - |
| |
| - | ''I was curious as to know how come, in a book strictly about API design in Java, you do not mention exceptions (particular checked exceptions) and the role they play in documenting assertions vs. hampering versionability. Did you simply think this to be too controversial an issue I wonder?''
| |
| - |
| |
| - | Good question! Inspiring. Here are my current answers: [[APIDesignPatterns:Exceptions|exceptions in API]].
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 21:37, 14 September 2008 (UTC)
| |
| - |
| |
| - |
| |
| - | ==== Have You Ever Wondered? ====
| |
| - |
| |
| - | Many people want to know, before they start to read a book, whether it can help them solve some problems they have faced. That is very likely reason why many books start with ''have you ever wondered'' sections. The ''Practical API Design'' book does not contain such section itself, however that in no way means that there it is not helping to solve problems! You can bet that there is a lot of useful advices! The book is a lab journal describing adventures of NetBeans project and as such, it is almost completely stuffed with problem solutions. Here is short [[Have You Ever Wondered|online]] version of [[Have You Ever Wondered]] to demonstrate that. Visit the [[Have You Ever Wondered|page]] and check yourself what problems can [[TheAPIBook]] solve for you!
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 20:42, 17 August 2008 (UTC)
| |
| - |
| |
| - | ==== Request/Response Pattern Revisited ====
| |
| - |
| |
| - | Here is few additional [[Blogs:JaroslavTulach:Practical Design:Request/Response Pattern Revisited|thoughts about Request/Response]] which did not make it into [[TheAPIBook]]'s explanation of [[APIDesignPatterns:RequestResponse|Request/Response]] pattern.
| |
| - |
| |
| - | --[[User:JaroslavTulach|JaroslavTulach]] 21:02, 25 June 2008 (UTC)
| |
| | <endFeed /> | | <endFeed /> |
I'd like to announce few changes related to apidesign.org site.
The other change is that I am migrating the whole website to new hosting infrastructure. Sources are up, mediawiki as well. However I still need to recover mailing lists, etc. If you find something that is not working and should, please Talkback. Thanks in advance.
Do you remember my recent post about object oriented encapsulation and performance? It was written in a response to an article that claimed C is much better than C++. There in given example nicely illustrates that by giving up on encapsulation one can implement more effective linked list. In my recent post I managed to prove that by using traits, one can easily get the same performance while keeping encapsulation in modern object oriented language. Only one question remained: Can one do the same with C++ templates?
Follow
