E2XR

"The most effective debugging tool is still careful thought, coupled with judiciously placed print statements." -- Brian Kernighan. Cutting a patient open and using print for debugging used to be the best way to diagnose problems. If you still advocate either one of those as the superior approach to troubleshooting, then you're either facing a very niche problem or need to update your knowledge. This is a frequent occurrence, e.g., this recent tweet: This specific tweet got to the HN front page, and people chimed in with that usual repetitive nonsense. No, it’s not the best way for the vast majority of developers. It should be discouraged just as surgery should be avoided when possible. Fixating on print debugging is a form of a mental block; debugging isn’t just stepping over code. It requires a completely new way of thinking about issue resolution. A way that is far superior to merely printing a few lines. Before I continue, my bias is obvious. I and I . This is a pet peeve of mine. , wrote a book about debugging blog about it a lot I want to start with the exception to the rule, though: when do we need to print something... Logging is NOT Print Debugging! One of the most important debugging tools in our arsenal is a logger, but it is not the same as print debugging in any way: Logger Print Permanence of output Permanent Ephemeral Permanence in code Permanent Should be removed Globally Toggleable Yes No Intention Added as part of design Added ad-hoc A log is something we add with forethought. We want to keep the log for future bugs and might even want to expose it to the users. We can control its verbosity often at the module level and can usually disable it entirely. It’s permanent in code and usually writes to a permanent file we can review at our leisure. Print debugging is code we add to locate a temporary problem. If such a problem has the potential of recurring, then a log would typically make more sense in the long run. This is true for almost every type of system. We see developers adding print statements and removing them constantly instead of creating a simple log to track frequent problems. There are special cases where print debuggings makes some sense, in mission critical embedded systems a log might be impractical in terms of device constraints. Debuggers are awful in those environments, and print debugging is a simple hack. Debugging system-level tools like a kernel, compiler, debugger, or JIT can be difficult with a debugger. Logging might not make sense in all of these cases, e.g., I don’t want my JIT to print every bytecode it’s processing and the metadata involved. Those are the exceptions, not the rules. Very few of us write such tools. I do, and even then, it’s a fraction of my work. For example, when working at Lightrun, I was working on a production debugger. Debugging the agent code that’s connected to the executable was one of the hardest things to do. A mix of C++ and JVM code that’s connected to a completely separate binary... Print debugging of that portion was simpler, and even then, we tried to aim towards logging. However, the visual aspects of the debugger within the server backend and the IDE were perfect targets for the debugger. Why Debug? There are three reasons to use a debugger instead of printouts or even logs: Features - modern debuggers can provide spectacular capabilities that are unfamiliar to many developers. Sadly, there are very few debugging courses in academia since it’s a subject that’s hard to test. Low overhead - in the past, running with the debugger meant slow execution and a lot of overhead. This is no longer true. Many of us use the debug action when launching an application instead of running, and there’s no noticeable overhead for most applications. When there is overhead, some debuggers provide means to improve performance by disabling some features. Library code - a debugger can step into a library or framework and track the bug there. Doing this with print debugging will require compiling code that you might not want to deal with. I dug into the features I mentioned in my book and series on debugging (linked above), but let’s pick a few fantastic capabilities of the debugger that I wrote about in the past. For the sake of positive dialog, here are some of my top features of modern debuggers. Tracepoints Whenever someone opens the print debugging discussion, all I hear is, “I don’t know about tracepoints”. They aren’t a new feature in debuggers, yet so few are aware of them. A tracepoint is a breakpoint that doesn’t stop. It just keeps running. Instead of stopping, you can do other things at that point, such as print to the console. This is similar to print debugging, only it doesn’t suffer from many of the drawbacks: no runtime overhead, no accidental commit to the code base, no need to restart the application when changing it, etc. https://www.youtube.com/watch?v=eXRqKqSp7x0&embedable=true Grouping and Naming The previous video/post included a discussion of grouping and naming. This lets us group tracepoints together, disable them as a group, etc. This might seem like a minor feature until you start thinking about the process of print debugging. We slowly go through the code, adding a print and restarting. Then suddenly, we need to go back, or if a call comes in and we need to debug something else... When we package the tracepoints and breakpoints into a group, we can set aside a debugging session, much like we set aside a branch in version control. It makes it much easier to preserve our train of thought and jump right back to the applicable lines of code. Object Marking When asked about my favorite debugging feature I’m always conflicted, ... It seems like a simple thing; we can mark an object, and it gets saved with a specific name. Object Marking is one of my top two features However, this is a powerful and important feature. I used to write down the pointers to objects or memory areas while debugging. This is valuable as sometimes an area of memory would look the same but would have a different address, or it might be hard to track objects with everything going on. Object Marking allows us to save a global reference to an object and use it in conditional breakpoints or for visual comparison. https://www.youtube.com/watch?v=DGjVVKCNosM&embedable=true Renderers My other favorite feature is ; it lets us define how elements look in the debugger watch area. Imagine you have a sophisticated object hierarchy but rarely need that information... A renderer lets you customize the way IntelliJ/IDEA presents the object to you. the renderer https://www.youtube.com/watch?v=oaUf8KXHsd0&embedable=true Tracking New Instances One of the often overlooked capabilities of the debugger is . A Java debugger can show you a searchable set of all object instances in heap, that is a fantastic capability that can expose unintuitive behavior But it can go further, it can track new allocations of an object and provide you with the stack to the applicable object allocation. memory tracking https://www.youtube.com/watch?v=dFOFOEg2W4k&embedable=true Tip of the Iceberg I wrote a lot about debugging, so there’s no point in repeating all of it in this post. If you’re a person who feels more comfortable using print debugging, then ask yourself this: why? Don’t hide behind an out-of-date Brian Kernighan quote. Things change. Are you working in one of the edge cases where print debugging is the only option? Are you treating logging as print debugging or vice versa? Or is it just that print debugging was how your team always worked, and it stuck in place? If it’s one of those, then it might be time to re-evaluate the current state of debuggers. Also published . here

Stop Cutting Your Patients Open: Rethinking Print for Debugging 

It's been a big week. I'm currently reviewing the final draft of . This is always a sobering and exciting moment. A moment in which all of a sudden all the months of work become "real". my upcoming debugging book I also recorded 9 videos for youtube bringing up the total videos in the course to 29 (with many more on the way). I'm starting two additional free courses, . one targeted at absolute beginners Another one is about modern Java programming which I'll launch really soon. Both will be free on my (obligatory "like, subscribe, and share"). youtube channel In this week’s post, we'll talk about breakpoints. It's a long one since what we mean when we say breakpoint is really just "line-breakpoint". There's a lot more to them as you can see below. www.youtube.com/watch?v=eXRqKqSp7x0 Transcript Welcome back to the fourth part of debugging at Scale where we kick ass and take names. Variable names! In this section, we discuss breakpoints which are the most basic units of work when debugging. But there’s so much more to them than just breaking. We talked about the most basic breakpoint in our first installment. This time, we’ll dig a bit deeper and into some of the lesser-known nuances. Conditional Breakpoints We start with conditional breakpoints. Conditional breakpoints let us define a condition for a breakpoint hit. This prevents the thread from stopping constantly on a breakpoint. I discussed this before with the myThread marker object we created in the previous video. In this case, we only stop if it’s different from the current thread. That means this breakpoint will only hit if a different thread invokes it. It’s a great way to detect thread-related problems like deadlocks or races. This feature is worth repeating since it’s such an important feature. Method Breakpoints Method breakpoints are pretty problematic. As a refresher, we can place a line breakpoint on any line in the method, and the breakpoint will stop there. This is so ubiquitous that we just call it a “breakpoint”. We can toggle the standard line breakpoint with control-F8 or alternatively on a mac with . Command-F8 Method breakpoints stop when we enter a method. You might think this is useless. Why not use a line breakpoint? You’d be right. Method breakpoints are much slower, and you shouldn’t use them: for this…  There is a use case for method breakpoints though. Notice that because method breakpoints are so slow, they are usually emulated by the IDE. It just uses line breakpoints to simulate method breakpoints. This is mostly seamless to us as users of the IDE but we need to know about it because, in the past, this wasn’t the case. You can still find messages from users on StackOverflow complaining about the slowness of method breakpoints. To see the use case for method breakpoints, let’s go into the manage breakpoints window. Say we want to break on all the methods starting with the letters I and S in classes whose name starts with Prime. We can do this by using an expression like this to stop on all such methods based on a pattern. This might seem far-fetched but is actually very useful if you have an abstract base class whose subclasses follow a naming convention and they have many related methods. You want to track everything, and you can do that using this approach. Notice you can also use tracepoints here and get very deep logging. We’ll discuss tracepoints in a few minutes. Field Watchpoints Field watchpoints aren’t your typical breakpoint. A watchpoint will stop every time the value of the field changes or every time it’s read. This is a remarkably cool way to catch a case where some code mutates a variable or finds out how a field value propagates into the code. Notice we can tune whether it stops at read operations, write operations, or both using this dialog. We can also make the watchpoint conditional just like we can with any other breakpoint. It’s called a watchpoint and not a breakpoint because it isn’t the point where the code stops. It stops at the point of access, not on the field itself. Breakpoint Management IDEs provide a management UI for all the breakpoints. We can manage the breakpoints we already have and create new breakpoints in the view breakpoints menu. I can open it via the view breakpoints menu option, or I can use key combination. Shift-Control-F8 Notice that, on a mac, we need to use command instead of the control key. In this dialog, we can disable, delete, and edit breakpoints. You’ll notice we have a lot of options here that we’ll discuss soon. We can add breakpoints from here. There are several interesting options, but now, I’ll just add a simple field breakpoint. Exception Breakpoints Suck (Or Do They?) We can set a breakpoint to stop when an exception is thrown. But it’s a bit of a problem. I have two options. First, I can catch a specific exception by name. This is useful if you know in advance the exception that will be thrown. But I can’t think of many cases where this happened, and I didn’t already know the line where the exception is thrown. The more valuable use case is catching all exceptions. The reason this is useful is that I sometimes might not look at the console while debugging. Exceptions might be logged there and I might miss them entirely. I might restart the debug session and might miss these exceptions. But if a breakpoint suddenly stops on an exception, that’s hard to miss. The problem is that catching all exceptions is broken by default! Unfortunately, this is hard to show in a simple prime main application, so I switched the demo to a simple spring boot application. The content of the application isn’t important for this case. Let’s enable catching any exception and see what happens… After enabling the catch, I try to continue, but it instantly hits the breakpoint again and again and again. The code polls a WebService in the background. That WebService is missing an HTTP header so the code that parses that header fails on a NumberFormatException. We’re stuck on the code that throws that exception which is valid as Java didn’t provide another way to parse numeric headers when that code was written. So what can we do? This effectively makes stopping on any exception useless for almost any real-world application. Let’s move the window a bit and then zoom in to see what we’re doing here. Now we can define a class filter. Notice I prefix both filters with a minus character to turn this into an exclusion filter. Here, I define a filter for all java packages and all sun packages. That means that every exception that’s handled within these packages won’t break. Once I press OK, I can press continue, and the application runs without breaking on the problematic exceptions. Other exceptions will work as usual and let us know when something breaks in our code! It’s amazing that this isn’t the IDE default. Without it, the feature is practically useless. Tracepoints (AKA Logpoints) Tracepoints or LogPoints are some of the most important types of breakpoints we have. We can add a tracepoint by shift-clicking on the gutter. This opens up a familiar breakpoint dialog, but it looks a bit different. First off, notice this: The suspend option is unchecked; notice that we can convert any breakpoint to a tracepoint by unchecking the suspend checkbox. By default, a breakpoint breaks. It stops the current thread and suspends it so we can leisurely inspect the application stack and see what’s going on. A tracepoint doesn’t suspend the current thread. The application hits the breakpoint and then keeps on running without stopping. This is pretty groundbreaking, how do you step over? Well, you don’t. Instead, we can do several other things… We can log the words “breakpoint hit” whenever we hit the breakpoint, but this isn’t that helpful unless we have only one tracepoint and only want to know if we reached that point. We can print a stack trace every time we reach the tracepoint which is more useful indeed. But not by much. It’s hard to read a lot of traces in a list and follow through. What I want to focus on is something else. Notice that evaluate and log already had the value in it because I had the value selected in the IDE before shift-clicking in the gutter. cnt cnt We can write any expression we want to print here. I can invoke a method to write descriptive strings, etc. This is literally a standard log statement that I can add dynamically to the code. Notice that I can still make this tracepoint conditional just like any conditional breakpoint. That means I can print any value at this point in time. Just like any logger. This is a spectacular feature. Imagine the method breakpoints we discussed earlier with these tracepoints; we can instantly log at scale. Let’s press OK. And then run this program; we can see the log we added in the tracepoint printed to the console as if we wrote it in the code! Grouping and Naming Grouping and naming are crucial once we scale up our debugging. We can name a breakpoint using the description to indicate its semantic meaning. This is very helpful when we work with many breakpoints. We can also group them based on files, packages, etc. But the cool thing is that we can create custom groups for breakpoints and disable the breakpoints in the group with one toggle. That’s very convenient!' It saves us from tediously pressing continue when trying to reach a state and lets us manage many breakpoints. But the true value here is at scale. Say you have a complex debugging session with multiple tracepoints running concurrently. You can group the session and disable the breakpoints while switching to a different branch to debug something else. Then go back to where you were when you’re done. Disable Breakpoint Sometimes a breakpoint is constantly hit, and we only need a specific stack. We can disable a breakpoint until a different breakpoint or an exception is hit, at which point the breakpoint will become enabled automatically. This saves us the need of pressing continue all the time if we only want to test a specific pathway. This also works with exceptions and exception breakpoints, and we can decide on the behavior after. Do we want to disable it again or continue as usual? This is very useful for the case of a failure that only goes through a specific pathway. I can add a tracepoint to the first method. Then disable the actual breakpoint I want in that tracepoint. Instance Filters Instance filters let us only accept a breakpoint from a specific object instance. Notice the instance of the current object marked as “this” in the watch. Notice it’s got the at symbol followed by the number 656. This is the Java object ID which is equivalent to a pointer in other programming languages. In instance filters, we can limit the breakpoint so it’s only hit for a specific object. Say this line breakpoint gets hit a lot by multiple instances but I only care about results from a specific object instance and want to filter out all the noise. I can open the advanced details dialog by clicking here. I need to check the instance filter option, and then type in the object ID of the instance I want to filter. This will mean the breakpoint won’t stop for other instance types. To apply this change, I press done. At this point, we can see the instance filter is still stopping at the breakpoint which is expected… So the next step is to change the instance filter to a different object instance. I’m making up a number since this is just for a test. Notice that when I right-click the breakpoint, I get a customized version of this dialog because we have an instance filter in place. This is a really neat feature that makes the UI so much easier to work with. Now that we’ve made that change, the breakpoint no longer breaks. Class Filters Class filters don’t make sense for a typical line breakpoint. Class filters make sense when using a field watchpoint or an exception breakpoint. In this case, I have a public field. I filter the access to the field to ignore all access from the prime main class. If a different class accesses the field, the breakpoint will hit. This is very useful, otherwise, I might get a lot of hits on the watchpoint from the current class. But I want to see other cases. Caller Filters Caller filter implements a filter based on the signature of the invoking method. To use it, we again need to go to the advanced menu. It supports wildcards so I can limit the caller to only allow the run method. Notice that it uses JVM notation for method signature which is a pretty complex subject I’ll discuss later. I have a section covering that in my debugging book. The method keeps stopping at the breakpoint as expected because, as we can see here, the run method is indeed in the stack trace. So, the filter applies properly and hits the breakpoint. We can again customize the breakpoint in the quick edit UI for the filter. In this case, I changed the filter to look for a method called stop which doesn’t exist, and indeed, the breakpoint no longer breaks. Final Word This has been a long video, I hope you found it educational and comprehensive. In the next video, we’ll talk about debugging streams and collections. If you have any questions, please use the comments section. Thank you!

Breakpoints: What They Are and Why They're So Powerful

Breakpoints: el poder masivo que han explicado

Points d'arrêt : la puissance massive qu'ils ont expliquée

ब्रेकप्वाइंट: द मैसिव पावर उन्होंने समझाया है

ブレークポイント: 彼らが説明した巨大な力

Breakpoints: o enorme poder que eles explicaram

Điểm dừng: Sức mạnh to lớn mà họ đã giải thích

断点：他们解释的巨大力量

It's been a few weeks since I've done this, but while looking at my , I saw one of my old Vue.js posts getting some activity: . In that blog post, I showed how to take a user-selected file and check the file size and dimensions of an image. As I've been slowly going through my Vue.js posts and creating versions, I thought this would be a perfect fit. new stats Reading Image Sizes and Dimensions with Vue.js Aline.js I'm not going to repeat everything from the previous entry, but let me recap the highlights. Obviously, your client-side code can't go into the user's machine and read ad hoc files. What it can do is get information about a file. This can be done with an tag using . user selected input type=file Immediately after selecting the file, your code has access to the file size. To get the dimensions though, you need to do a bit of work. First, create a new object. Image You need to set the source of the image to the contents of the file. This can be done by using a . data URL Once the image is loaded (remember, images have an event), you can then check the dimensions. onload Ok, so given the above, let's build a quick demo. First, the HTML. I'm just going to have the input field and a place to print out details about the image. <div x-data="app">
    
    <input type="file" x-ref="myFile" x-on:change="selectedFile" accept="image/*"><br/>

    <template x-if="imageLoaded">
        <p>
        Image size is <span x-text="image.size"></span><br/>
        Image width and height is <span x-text="image.width"></span> / <span x-text="image.height"></span>
        </p>
  </template>
</div> A few things to note here. Like Vue, we sometimes need to reach out to the DOM, and like Vue, this is done via . You can see my setting to gain access to the input field directly. Also, note I'm using the event. This will fire when the user selects a file. Now let's look at the code. refs x-ref="myFile" change document.addEventListener('alpine:init', () => {
  Alpine.data('app', () => ({
        imageLoaded:false,
        image: {
            size:null,
            width:null,
            height:null
        },
        selectedFile() {
            this.imageLoaded = false;

            let file = this.$refs.myFile.files[0];
            if(!file || file.type.indexOf('image/') !== 0) return;

            this.image.size = file.size;

            let reader = new FileReader();
            reader.readAsDataURL(file);

            reader.onload = evt => {
                let img = new Image();
                img.onload = () => {
                    this.image.width = img.width;
                    this.image.height = img.height;
                    this.imageLoaded = true;
                }
                img.src = evt.target.result;
            }

            reader.onerror = evt => {
                console.error(evt);
            }
        
        }
    
    }))
}); My Alpine app has two main variables, and . The only real logic is in . This will use to grab the input field and the selected image. I then use a object to read in the bits, set it to the image, and when is fired, I can update my variables to the front-end displays. Given this source image for example: imageLoaded image selectedFile $refs FileReader onload If I select it, I'll see this: You can test this yourself using the CodePen below: https://codepen.io/cfjedimaster/pen/ExRMeZO?embedable=true Ok, so as I did in the , let's consider a simple example that adds validation. Specifically - a max file size, a max width, and a max height. The HTML is mostly the same except now I show an error on a validation failure: previous post <div x-data="app">
    
    <input type="file" x-ref="myFile" x-on:change="selectedFile" accept="image/*"><br/>

    <template x-if="imageError">
    <p class="imageError" x-text="imageError">
    </p>
    </template>
</div> In the JavaScript, I added constants for my max values: const MAX_SIZE = 100000;
const MAX_WIDTH = 500;
const MAX_HEIGHT = 300; And here's the Alpine app itself: document.addEventListener('alpine:init', () => {
    Alpine.data('app', () => ({
        imageError:'',
        image: {
            size:null,
            width:null,
            height:null
        },
        selectedFile() {
            this.imageError = '';

            let file = this.$refs.myFile.files[0];
            if(!file || file.type.indexOf('image/') !== 0) return;

            this.image.size = file.size;
            if(this.image.size > MAX_SIZE) {
                this.imageError = `The image file size (${this.image.size}) is too much (max is ${MAX_SIZE}).`;
                return;
            }

            let reader = new FileReader();
            reader.readAsDataURL(file);

            reader.onload = evt => {
                let img = new Image();

                img.onload = () => {
                    this.image.width = img.width;
                    this.image.height = img.height;

                    if(this.image.width > MAX_WIDTH) {
                        this.imageError = `The image width (${this.image.width}) is too much (max is ${MAX_WIDTH}).`;
                        return;
                    }
                    if(this.image.height > MAX_HEIGHT) {
                        this.imageError = `The image height (${this.image.height}) is too much (max is ${MAX_HEIGHT}).`;
                        return;
                    }

                }
                img.src = evt.target.result;
            }

            reader.onerror = evt => {
                console.error(evt);
            }
        }
    }))
}); For the most part, this is the same, with the only change being that now I check the various properties and set a new variable, , when something fails validation. You can test this below: imageError https://codepen.io/cfjedimaster/pen/rNKRYYz?embedable=true I'll repeat myself, which my readers know I like to do, but the more I use Alpine, the more it just clicks with me. Also published . here

How to Read Image Sizes and Dimensions with Alpine.js

Many crypto investors look back on 2017 with nostalgia: at that time Bitcoin rate skyrocketed almost by 20 times! Those who have already purchased the asset are waiting for it to reach “to the moon” level again, but novice traders have the jeebies, because not everyone can buy even 1 BTC right away. Today there are many examples of successful investments in low-cost altcoins. But buying up everything awaiting growth is the wrong strategy. Which cryptocurrency is really worth your time and money, as well as when is the most favorable moment for investment? What to focus on when investing in cryptocurrencies? For sure, it’s up to everyone to decide what currency to invest in and how much. But beginners should remember a simple rule, which has no exceptions: you need to invest the money you’re not afraid to lose. Even while investing a small amount, you need to evaluate the asset and its position in the market by . analyzing several criteria 1. Product Today, the main trend is the exit of altcoins that are not backed up by a real product from the market. Choosing out of the remaining coins, you need to answer a few questions: The growth of many cryptocurrencies happens only due to the speculation of traders for quick profits, but there may not be a real product behind the asset. Such coins have a right to exist, but the increase in the rate in this case is very unstable. What real problem does the coin solve? You can find out it by visiting exchanges where the cryptocurrency is traded. The high liquidity of the coin shows that investors are really interested in it, and the high level of buying and selling will push the rate up. How actively is the coin used? In order to attract customers, developers often add the “blockchain” prefix to their product, just to do slap dash. Check if the distributed blockchain is really used in business processes, or is it just a hype. Is blockchain really being used? 2. Success in ecosystem expansion It is worth paying attention to whether the coin scales its functional capability. Support of an asset by an increasing number of platforms will lead to a stable price surge. Moreover, additional options for using cryptocurrency will definitely attract new users and, accordingly, investors. It turns out that high community involvement, along with the popularization of cryptocurrency, creates a full-fledged ecosystem that allows to bring the product to a higher level. 3. References in the media Don’t forget that any publication, even from well-established editions, can be purchased. Therefore, pay attention to what exactly is written in the articles about the project. If there are no publications at all – it is a bad sign. Journalists of specialized media resources will definitely write about a serious project. 4. Increase in value It is necessary to understand how the rate of the cryptocurrency will grow. For example, if it is used only for making internal payments on the platform, then its growth can occur only with an increase in the number of transactions. Simply put, the more demand, the higher the price. In addition to internal basic factors, you also need to draw attention to external ones. Assess the general state of the cryptocurrency market. If it recedes, and negative news prevails in the world, as for example was with the outbreak of coronavirus, then it is probably inopportune time to buy assets. Study the news of the cryptocurrency itself: if positive messages about the conclusion of partnerships, rebranding, the launch of new tools prevail, the rate is likely to creep upward. In this case, put the coin to your portfolio and expect growth – it will not keep you waiting long. But if you see that the development of the project is at a standstill, and the team is hiding reports on the work done, then investing in such a currency is definitely not worth it. Example Let's consider the above mentioned points using the example of one of the promising gaming altcoins – IQN. IQN token was created to give players an additional opportunity to monetize their achievements by competing in games of all genres. Product. Why is the product promising? Firstly, it is involved in a multi-billion dollar gaming industry, the profit of which is growing every year. Secondly, it solves the issue of monetization, which today bothers a lot of gamers. For the effort and time spent, they, one way or another, want to get income. IQN gives them this opportunity by prioritizing the player's skills. Today, the token is traded on , , , Exrates и Yobit.net, which proves that players receive assets for their in-game achievements, and crypto traders willingly purchase assets. HitBTC EXMO BitForex The token is actively integrated by gaming platforms in order to motivate their users and give gamers a chance to turn their efforts into an asset. Ecosystem expansion. For example, became the first ecosystem which integrated IQN. This made it possible for players to monetize their progress in games and receive winnings without intermediaries. Players already receive IQN by competing with each other, for participating in various contests and activities held by the platform's team and for winning weekly challenges. PvP gaming platform IQeon.com The expansion of the list of platforms which will integrate the token is an outspoken indicator that the gaming community is interested in a real opportunity to turn their time and energy into real assets. And with an increase in the number of motivated players, the value of the token will inevitably creep up, strengthening its position and opening up new prospects for the gaming industry. Recently, IQN was added to the listing of some of the world's leading platforms for secure digital asset trading – the oldest crypto exchange , the Singapore and the British exchanges. HitBTC BitForex EXMO Such an event created additional prospects for users of PvP gaming platform, and also positively affected the popularization of the asset and the growth of its price rate. IQeon.com The mention of IQN can often be seen in publications of crypto gaming portals. This shows the high interest of crypto enthusiasts and the real demand for the coin. Mentioning in meda. The token has set a course for growth: in just six months, the price of IQN has skyrocketed by 82%. Increase in value. Such a confident upward movement means that the token has not yet formed an unambiguous bar of maximum value. Along with the growth, there are local price adjustments, however, it is difficult to find sharp and at the same time protracted falls on the chart, as it is often observed among TOP cryptocurrencies. It should be understood that if the project continues to expand the list of games, applications and services that support IQN, then investors will really benefit. Conclusion First of all, there is always a need for thorough analysis, so as not to face weak or depreciating altcoins. Depreciating tokens not always mean “unpromising”, but it should be understood that the cryptocurrency market is very volatile. Prices can change at any time and sometimes for no reason. Therefore, unstable coins bear a real danger to investors. Since 2017, this category of coins has grown significantly, which makes them much more difficult to recognize in the market. Weak cryptocurrencies are showing speculative growth, attracting newbies who want to get rich in short terms. But such assets are not supported by anything: they have no idea behind, they are rarely mentioned, the team provides a minimum of information about the project and is reluctant to communicate with the community. Therefore, you can minimize the "surprise factor" by doing a deeper investigation. Purchase digital assets with a long-term perspective only. Due to the high volatility, no one can guarantee profitability in the short term.

What's The Right Time To Start Buying Crypto?

The annual turnover of the gaming industry exceeds billions of dollars. E-sports events gather thousands of fans around the world. More and more gamers are trying to make games their profession, and new products are released every day. However, the more competition there is in the gaming market, the less truly unique projects can be found. Read more about the main characteristics of the platform, available functions and its capabilities in my review. General overview IQeon is an Estonian blockchain startup developing gaming platform which provides the ability to monetize in-game achievements. The peculiarity of the project is that there is an internal digital currency used on the platform – IQN. In user PvP matches, players can earn an asset for winning, use it to participate in games of the ecosystem and exchange it for other currencies on popular trading platforms Yobit, Exrates and Token Store. Platform feature set Thanks to user-friendly and convenient interface, any player who is not even familiar with cryptocurrencies can get a sense of the platform’s functionality. There are several main blocks on the main page: Catalog of games with filtering by genre, Catalog with sorting games by popularity and time of addition, Player’s personal account, which displays the balance of available IQN, activity history, as well as general information about user’s profile. Games catalog The platform offers over 30 games of various genres: from racing and shooters to strategies and intellectual quizzes. There are 6 more games in development that will be released in the near future. The game library is constantly updated with new games. Flexible development of the platform allows to quickly and efficiently introduce new games and, as a result, gives more opportunities for users to monetize their achievements. There are filtering by genre, popularity, recommendations and time of addition presented for quick access to games in the catalog. After authorization on the platform, the player get access to free PvP matches, as well as games that provide the opportunity to win IQN digital currency. In the latter case, after clicking "Play" button, the user must indicate the number of IQN that he is ready to contribute to the match, select the number of opponents and only after that start the competition for the main prize. Unregistered users can also play on the platform, however, only in training single player mode. On the home page, users can also follow the game progress, which is shown in the leaderboard with the best players of the month. IQeon platform positions itself as an entertainment platform where you can monetize gaming achievements, and, moreover, as an honest and open community where you can find like-minded people. For these purposes, the platform has a chat in which users can discuss games, find and arrange matches, and also post their questions. Support service on the platform is available 24/7. Personal account In the personal account, a player can edit his profile, track activity in the games under “My Games” tab, and also see the available balance of IQN digital asset. The user can add an active cryptocurrency wallet to the profile for subsequent deposit or withdrawal of funds from the platform. He also has access to a complete transaction history. After registering and adding a wallet to the platform, a window with available deposit/withdrawal options appears in the user's account. In order to make a deposit to the platform, you need to copy the e-wallet address in the pop-up window and deposit the account through the user's existing crypto wallet. You can get IQN on a gaming account not only through a deposit. The digital asset is also credited by the project team for outstanding gaming achievements on the gaming platform, winning in Weekly Challenge contest, participating in promotions and platform activities, as a gift from other players. IQN can be used to participate in game matches, as well as be exchanged at popular trading platforms Yobit, Exrates, Token Store and subsequently withdrawn to fiat money. The platform’s internal currency operates on the basis of Ethereum blockchain. For IQeon team, the use of this technology is, first of all, ensuring the reliability of the platform, since the payment of winnings is guaranteed by a smart contract. Conclusion Thus, IQeon project is an excellent motivation for players around the world to earn money while doing their favorite thing. The platform has several important advantages for players. So, users can: Mo
netize their gaming achievements; Exchange digital asset for fiat or other assets; Use IQN as a means of payment in all games of the ecosystem; Conduct transactions without commission; Have open access to the history of all operations. The project is promising not only for gamers. Developers can also offer their games for integration with IQeon.com. The blockchain gaming market has not yet been formed. Many games using distributed registry technology are just a gamification of trading, a simulator of digital asset trading, where the gameplay is a secondary detail. However, the connection between the game market, cryptocurrencies and blockchain technology is becoming increasingly strong and will soon get to be absolutely inextricable. And IQeon team keeps up with the times, emphasizing the transparency and fairness of gaming competitions.

The Future of Games Lies In Blockchain: An Overview of Our Gaming Platform

How to create Elixir Releases. And some tips for Phoenix, Ecto, and umbrella applications. A Quick Refresher and a Bit of History Releases have long been around in the Erlang/OTP world. I have previously written about . Here is a little refresher: Releases are self-contained bundles of compiled Elixir/Erlang that can easily be deployed on e machines. what Releases are and why they’re great in more detail code remot Naturally, most tools for creating Releases have so far come from the Erlang world. Erlang ships with and , but their usage is rather complicated. So the community built as an easier-to-use alternative that has now become the de-facto standard for creating Releases from Erlang projects. Since those tools are all made to work with Erlang, they work with Elixir projects but leave much to be desired. systools reltool [relx](https://github.com/erlware/relx) can In 2014, Paul aka set out to make Elixir Releases easier and published — built on top of with some Elixir-specific features. Due to limitations of , was inflexible and never able to leverage the full potential of modular Elixir applications. So Paul decided to create a new Release manager, written from scratch in pure Elixir — and so was born. bitwalker exrm relx relx exrm Distillery Step-by-step guide In this section of the article, you’ll learn how to add Distillery to a project and build your first release step-by-step. Let’s go! I have created a small application that prints out the current time every second. We can use it to build a Release: git clone cd distillery-demo https://github.com/wmnnd/distillery-demo.git Installing Distillery & Creating the First Release Before you can create your first Release, you need to install Distillery. Add to the list of dependencies in your project’s and run . {:distillery, "~> 1.5"} mix.exs mix deps.get Next, we initialize Distillery by calling . This command creates a configuration file . You could also manually create the file but it’s more convenient like this. mix release.init rel/config.exs We will look at the contents of the configuration file in a bit. For now it’s enough to build our first Release. In order to do that, run . Distillery will now create an output that looks something like this: mix release ==> Assembling release..==> Building release clock:0.1.0 using environment dev==> You have set dev_mode to true, skipping archival phase==> Release successfully built!You can run it in one of the following ways:Interactive: _build/dev/rel/clock/bin/clock consoleForeground: _build/dev/rel/clock/bin/clock foregroundDaemon: _build/dev/rel/clock/bin/clock start Congratulations, you have just created your first Release! Run it with . As expected, the application now prints out the current time in one-second intervals. You can terminate the application by hitting . _build/dev/rel/clock/bin/clock foreground Ctrl+C Note: There is currently a bug in Distillery that might crash the Release when starting it. In this case, run **mix clean && mix compile** and try running the application again. In the call to start the application, you passed the command at the end. This is the . There are also other boot commands for starting an application: launches an interactive iex session with your application and creates a daemon process in the background. foreground boot command console start Release Profiles and Environments Let’s take a step back. You’re probably already familiar with Elixir’s build tool Mix. Mix supports multiple : , and . Depending on the current environment, Mix can, for example, determine which dependencies or configuration files to include. environments dev prod test You might have noticed that when we created the Release, Distillery printed out this line: . Distillery also has but they are different from Mix environments. Building release clock:0.1.0 **using environment dev** environments — Distillery uses environments to allow for multiple configurations of the Release building process. Conveniently — or confusingly — Distillery environments are by default the same as the Mix environments. Let’s take a look at the auto-generated configuration file in order to better understand how profiles work: rel/config.exs use Mix.Releases.Config,default_release: :default,default_environment: Mix.env() We can see that is set to . This means that Distillery will match our Mix environment. You can override default environment with the switch. Here are some examples of how this could work: default_environment Mix.env() --env mix release#Mix environment and Distillery environment are both dev MIX_ENV=prod mix release#Mix environment and Distillery environment are both prod MIX_ENV=prod mix release --env=dev#Mix environment is , Distillery environment is prod dev The configuration file also specifies that is . This is because you can actually define more than just one Release for your project. With the setting, Distillery automatically picks the Release defined in . If you want to override the default Release, you can specify this with the flag. default_release :default :default first rel/config.exs --name You can pick a specific profile with the flag. The combination of an environment with a specific Release name is called a . profile --profile=name:env In the next section we’re going to take a look at how we can use multiple environments to configure Distillery. Release Build Configuration Our Distillery configuration includes two environments ( and ) on top of one Release named like our project ( ): dev prod clock environment :dev doset dev_mode: trueset include_erts: falseset cookie: :"W?cN_`G<>ayUI&ku{<$3w7J<^nUBRBu[F[…]"end environment :prod doset include_erts: trueset include_src: falseset cookie: "^_`fz{dk|`w.n3Z%T,n=F>ezazFk.1ci5}[…]"end release :clock doset version: current_version(:clock)set applications: [:runtime_tools]end Here is what the options included in the configuration file do: : If , bytecode, assets and other files are not copied to the Release folder. Instead, Distillery creates symlinks. This makes creating the Release faster and is great for testing purposes. dev_mode: true/false true : If , Distillery includes the Erlang Runtime ERTS. This is not necessary on your development machine but recommended for making self-contained Releases.If you want to deploy your Release to a machine with a different operating system or processor architecture, you can specify the path to a cross-compiled version of ERTS instead of . include_erts: true/false true true/false : Distillery can set the . The auto-generated configuration includes random Erlang cookies. Later in this post we’ll look into a better way to configure the magic cookie. cookie: $STRING Erlang cookie Don’t include a hard-coded cookie if you want to commit your configuration to a Git repository! : This option is available for with the Erlang Release tool . If , Erlang source code from your project and dependencies is included in the Release. Elixir code is never included, so most of the time, you can ignore this option. include_src: true/false backwards compatibility relx true : Sets the version of the Release. You can use the function to extract the version from your project’s . version: $VERSION_STRING current_version/1 mix.exs : Here you can list additional applications that you want to include. By default, Distillery includes which is part of the Erlang standard library and enables certain debugging features. applications: [:app_name] :runtime_tools Lifecycle Scripts aka Hooks It is possible to add shell scripts to your Release to run at certain points of your application’s lifecycle. These scripts are also referred to as and can be configured in your . Simply add them to an or section like this: hooks rel/config.exs env release environment :prod doset pre_start_hook: "rel/hooks/pre_start.sh"end Notice that the paths are relative to your project directory and not relative to the directory. The most interesting hook is certainly , but there is also , , , and . You can currently only configure one script per hook with Distillery although Erlang would theoretically allow for more. rel pre_start post_start pre/post_configure pre/post_stop pre/post_upgrade Umbrella Apps Distillery is also great when working with Umbrella apps! There are really only two things you need to pay attention to: Include the names of your child applications in the list of the Release configuration. applications You can choose to take the Release version number from any of the child applications by using . current_version(:my_child_app) As mentioned before, it’s also possible to define more than one Release in your and thus specify multiple Release profiles. This can be useful if you want to have Releases that only include certain child applications from your umbrella project. rel/config.exs Runtime Configuration With Releases Configuring Elixir applications — especially when it comes to third-party libraries, can be a tricky affair. Ecto core-developer Michał recently about the confusing status quo. voiced his concern The Problem with Mix Configuration The first thing you need to remember is that configuration in Mix configuration files is evaluated at compile-time. This is not a problem when you run your application from source code. But when Distillery builds a Release, all configuration files are evaluated at build-time. If you have anything like in a Mix.Config file, you’re out of luck. will take on the value of the environment variable from your build system. When you launch the application on another machine, the value won’t be updated. foo: System.get_env("BAR_VAR") foo BAR_VAR Fortunately, there are ways around this. The easiest one is a little trick employed by Distillery: A Simple Solution: REPLACE_OS_VARS Distillery has a special way of injecting environment variables into Mix configuration. Simply use a string like in your config file and you’re good to go. Distillery will replace it with the corresponding environment variable value when your application starts. All you need to do for this to work is setting the environment variable when launching your release. This makes it very easy to write configuration like this: "${BAR_VAR}" REPLACE_OS_VARS=true config :my_app,foo: "${BAR_VAR}" Use in your to set the cookie from an environment variable. This method is great for initializing the Erlang cookie. set cookie: "${ERLANG_COOKIE}" rel/config.exs doesn’t come without problems. Most importantly, this method only works with strings. If you try something like , you’ll get an error message because the compiler evaluates the expression before Distillery gets a chance to replace the special string. REPLACE_OS_VARS String.to_integer("${BAR}") Fortunately, many libraries now support a more flexible approach to configuration. Ecto Ecto has introduced a new way of dynamically configuring application dependencies. Their solution: A callback! You can dynamically configure Ecto with the callback. Ecto.Repo.init/2 This callback takes and the as arguments. We can safely ignore (which is either or , depending on the context of the call). is the configuration Keyword list from your Mix configuration. This is convenient because it allows you to set default values in your Mix configuration and then override them with environment variables. type config type :supervisor :dry_run config The callback has to return or . Here is a simple example with type conversion: {:ok, config} :ignore Instead of writing your own code for parsing environment variables, you might find a third-party application such as or useful. I haven’t tried them yet but they seem to have some nice convenience features. Atmo Confex Phoenix Creating a Release from a Phoenix application is easy. Before you create a production release, make sure your assets are built and digested: ./node_modules/brunch/bin/brunch b -pMIX_ENV=prod mix phx.digest With version 1.3, Phoenix has also adapted the Ecto’s callback-style configuration method. This makes it very easy to flexibly configure : Phoenix.Endpoint Upgrading Releases No (pretty) complete guide to Elixir Releases would be (pretty) complete without mentioning one of their coolest features: Hot updates. You probably know that Erlang and Elixir are compiled to bytecode which is then executed by the . And thanks to BEAM, we can upgrade an application without ever stopping it. BEAM virtual machine Creating an Upgrade Release Release upgrades internally use files to determine which modules should be upgraded and how. Fortunately for us, Distillery creates them automatically when we pass it the parameter. Otherwise, Distillery wouldn’t be able to determine which modules need updating. .appup --upgrade Make sure the previous Release is still available in your **/_build** folder when building an upgrade. Creating a Production Release Only Releases that include ERTS can use hot upgrading. So, let’s start by creating a production Release of our application: clock MIX_ENV=prod mix deps.getMIX_ENV=prod mix release #In Terminal 1 Now open up a second terminal window and launch the Release: #In Terminal 2cd distillery-clock-demo_build/prod/rel/clock/bin/clock foreground Again, you should see the current time printed out every second. Creating an Upgrade Release Let’s create a new version of . Since it prints out its current version number together with the current time, all you need to do to get a different output is change the in . Currently it’s set to . Let’s change it to . clock version mix.exs 0.1.0 0.2.0 Then, create an upgrade Release by passing the flag to . --upgrade mix.release MIX_ENV=prod mix release --upgrade #In Terminal 1 We’ll Do It Live! After the Release upgrade has been created, the Clock application in the second terminal hasn’t changed. Yet. Still in the first terminal, run the following command: #In Terminal 1_build/prod/rel/clock/bin/clock upgrade 0.2.0 In the second terminal, the Clock output will now change and start to also print out the current date. How neat! Updating an application wile it’s running! Are You a Master of Elixir Releases Yet? I hope that after reading this guide, you now have a better understanding of Elixir Releases . I certainly do after writing it! If you think I missed an aspect of Elixir Releases that should be part of this (pretty) complete guide, please let me know and I will try to add it! Upcoming articles will cover deployment strategies and building Docker images. This article is part of an ongoing series about developing and deploying Elixir applications to production. In this series I am sharing my experience from creating DBLSQD , a release and update server written in Elixir. Check it out, there is a 60-day no-strings-attached free demo: _DBLSQD is a release + update server for desktop and mobile apps. Powerful SDKs for Electron & Qt. Compatible with Sparkle, Squirrel & others._www.dblsqd.com Publish & Distribute Software — DBLSQD

Mastering Elixir Releases with Distillery — A (Pretty) Complete Guide

The Story Girl by L. M. Montgomery, is part of the HackerNoon Books Series. You can jump to any chapter in this book here . THE GHOSTLY BELL CHAPTER XVI. THE GHOSTLY BELL Friday was a comfortable day in the household of King. Everybody was in good humour. The Story Girl sparkled through several tales that ranged from the afrites and jinns of Eastern myth, through the piping days of chivalry, down to the homely anecdotes of Carlisle workaday folks. She was in turn an Oriental princess behind a silken veil, the bride who followed her bridegroom to the wars of Palestine disguised as a page, the gallant lady who ransomed her diamond necklace by dancing a coranto with a highwayman on a moonlit heath, and “Buskirk’s girl” who joined the Sons and Daughters of Temperance “just to see what was into it;” and in each impersonation she was so thoroughly the thing impersonated that it was a matter of surprise to us when she emerged from each our own familiar Story Girl again. Cecily and Sara Ray found a “sweet” new knitted lace pattern in an old magazine and spent a happy afternoon learning it and “talking secrets.” Chancing—accidentally, I vow—to overhear certain of these secrets, I learned that Sara Ray had named an apple for Johnny Price—“and, Cecily, true’s you live, there was eight seeds in it, and you know eight means ‘they both love’ “—while Cecily admitted that Willy Fraser had written on his slate and showed it to her, “If you love me as I love you, No knife can cut our love in two”— “but, Sara Ray, NEVER you breathe this to a living soul.” Felix also averred that he heard Sara ask Cecily very seriously, “Cecily, how old must we be before we can have a REAL beau?” But Sara always denied it; so I am inclined to believe Felix simply made it up himself. Paddy distinguished himself by catching a rat, and being intolerably conceited about it—until Sara Ray cured him by calling him a “dear, sweet cat,” and kissing him between the ears. Then Pat sneaked abjectly off, his tail drooping. He resented being called a sweet cat. He had a sense of humour, had Pat. Very few cats have; and most of them have such an inordinate appetite for flattery that they will swallow any amount of it and thrive thereon. Paddy had a finer taste. The Story Girl and I were the only ones who could pay him compliments to his liking. The Story Girl would box his ears with her fist and say, “Bless your gray heart, Paddy, you’re a good sort of old rascal,” and Pat would purr his satisfaction; I used to take a handful of the skin on his back, shake him gently and say, “Pat, you’ve forgotten more than any human being ever knew,” and I vow Paddy would lick his chops with delight. But to be called “a sweet cat!” Oh, Sara, Sara! Felicity tried—and had the most gratifying luck with—a new and complicated cake recipe—a gorgeous compound of a plumminess to make your mouth water. The number of eggs she used in it would have shocked Aunt Janet’s thrifty soul, but that cake, like beauty, was its own excuse. Uncle Roger ate three slices of it at tea-time and told Felicity she was an artist. The poor man meant it as a compliment; but Felicity, who knew Uncle Blair was an artist and had a poor opinion of such fry, looked indignant and retorted, indeed she wasn’t! “Peter says there’s any amount of raspberries back in the maple clearing,” said Dan. “S’posen we all go after tea and pick some?” “I’d like to,” sighed Felicity, “but we’d come home tired and with all the milking to do. You boys better go alone.” “Peter and I will attend to the milking for one evening,” said Uncle Roger. “You can all go. I have an idea that a raspberry pie for to-morrow night, when the folks come home, would hit the right spot.” Accordingly, after tea we all set off, armed with jugs and cups. Felicity, thoughtful creature, also took a small basketful of jelly cookies along with her. We had to go back through the maple woods to the extreme end of Uncle Roger’s farm—a pretty walk, through a world of green, whispering boughs and spice-sweet ferns, and shifting patches of sunlight. The raspberries were plentiful, and we were not long in filling our receptacles. Then we foregathered around a tiny wood spring, cold and pellucid under its young maples, and ate the jelly cookies; and the Story Girl told us a tale of a haunted spring in a mountain glen where a fair white lady dwelt, who pledged all comers in a golden cup with jewels bright. “And if you drank of the cup with her,” said the Story Girl, her eyes glowing through the emerald dusk about us, “you were never seen in the world again; you were whisked straightway to fairyland, and lived there with a fairy bride. And you never WANTED to come back to earth, because when you drank of the magic cup you forgot all your past life, except for one day in every year when you were allowed to remember it.” “I wish there was such a place as fairyland—and a way to get to it,” said Cecily. “I think there IS such a place—in spite of Uncle Edward,” said the Story Girl dreamily, “and I think there is a way of getting there too, if we could only find it.” Well, the Story Girl was right. There is such a place as fairyland—but only children can find the way to it. And they do not know that it is fairyland until they have grown so old that they forget the way. One bitter day, when they seek it and cannot find it, they realize what they have lost; and that is the tragedy of life. On that day the gates of Eden are shut behind them and the age of gold is over. Henceforth they must dwell in the common light of common day. Only a few, who remain children at heart, can ever find that fair, lost path again; and blessed are they above mortals. They, and only they, can bring us tidings from that dear country where we once sojourned and from which we must evermore be exiles. The world calls them its singers and poets and artists and story-tellers; but they are just people who have never forgotten the way to fairyland. As we sat there the Awkward Man passed by, with his gun over his shoulder and his dog at his side. He did not look like an awkward man, there in the heart of the maple woods. He strode along right masterfully and lifted his head with the air of one who was monarch of all he surveyed. The Story Girl kissed her fingertips to him with the delightful audacity which was a part of her; and the Awkward Man plucked off his hat and swept her a stately and graceful bow. “I don’t understand why they call him the awkward man,” said Cecily, when he was out of earshot. “You’d understand why if you ever saw him at a party or a picnic,” said Felicity, “trying to pass plates and dropping them whenever a woman looked at him. They say it’s pitiful to see him.” “I must get well acquainted with that man next summer,” said the Story Girl. “If I put it off any longer it will be too late. I’m growing so fast, Aunt Olivia says I’ll have to wear ankle skirts next summer. If I begin to look grown-up he’ll get frightened of me, and then I’ll never find out the Golden Milestone mystery.” “Do you think he’ll ever tell you who Alice is?” I asked. “I have a notion who Alice is already,” said the mysterious creature. But she would tell us nothing more. When the jelly cookies were all eaten it was high time to be moving homeward, for when the dark comes down there are more comfortable places than a rustling maple wood and the precincts of a possibly enchanted spring. When we reached the foot of the orchard and entered it through a gap in the hedge it was the magical, mystical time of “between lights.” Off to the west was a daffodil glow hanging over the valley of lost sunsets, and Grandfather King’s huge willow rose up against it like a rounded mountain of foliage. In the east, above the maple woods, was a silvery sheen that hinted the moonrise. But the orchard was a place of shadows and mysterious sounds. Midway up the open space in its heart we met Peter; and if ever a boy was given over to sheer terror that boy was Peter. His face was as white as a sunburned face could be, and his eyes were brimmed with panic. “Peter, what is the matter?” cried Cecily. “There’s—SOMETHING—in the house, RINGING A BELL,” said Peter, in a shaking voice. Not the Story Girl herself could have invested that “something” with more of creepy horror. We all drew close together. I felt a crinkly feeling along my back which I had never known before. If Peter had not been so manifestly frightened we might have thought he was trying to “pass a joke” on us. But such abject terror as his could not be counterfeited. “Nonsense!” said Felicity, but her voice shook. “There isn’t a bell in the house to ring. You must have imagined it, Peter. Or else Uncle Roger is trying to fool us.” “Your Uncle Roger went to Markdale right after milking,” said Peter. “He locked up the house and gave me the key. There wasn’t a soul in it then, that I’m sure of. I druv the cows to the pasture, and I got back about fifteen minutes ago. I set down on the front door steps for a moment, and all at once I heard a bell ring in the house eight times. I tell you I was skeered. I made a bolt for the orchard—and you won’t catch me going near that house till your Uncle Roger comes home.” You wouldn’t catch any of us doing it. We were almost as badly scared as Peter. There we stood in a huddled demoralized group. Oh, what an eerie place that orchard was! What shadows! What noises! What spooky swooping of bats! You COULDN’T look every way at once, and goodness only knew what might be behind you! “There CAN’T be anybody in the house,” said Felicity. “Well, here’s the key—go and see for yourself,” said Peter. Felicity had no intention of going and seeing. “I think you boys ought to go,” she said, retreating behind the defence of sex. “You ought to be braver than girls.” “But we ain’t,” said Felix candidly. “I wouldn’t be much scared of anything REAL. But a haunted house is a different thing.” “I always thought something had to be done in a place before it could be haunted,” said Cecily. “Somebody killed or something like that, you know. Nothing like that ever happened in our family. The Kings have always been respectable.” “Perhaps it is Emily King’s ghost,” whispered Felix. “She never appeared anywhere but in the orchard,” said the Story Girl. “Oh, oh, children, isn’t there something under Uncle Alec’s tree?” We peered fearfully through the gloom. There WAS something—something that wavered and fluttered—advanced—retreated— “That’s only my old apron,” said Felicity. “I hung it there to-day when I was looking for the white hen’s nest. Oh, what shall we do? Uncle Roger may not be back for hours. I CAN’T believe there’s anything in the house.” “Maybe it’s only Peg Bowen,” suggested Dan. There was not a great deal of comfort in this. We were almost as much afraid of Peg Bowen as we would be of any spectral visitant. Peter scoffed at the idea. “Peg Bowen wasn’t in the house before your Uncle Roger locked it up, and how could she get in afterwards?” he said. “No, it isn’t Peg Bowen. It’s SOMETHING that WALKS.” “I know a story about a ghost,” said the Story Girl, the ruling passion strong even in extremity. “It is about a ghost with eyeholes but no eyes—” “Don’t,” cried Cecily hysterically. “Don’t you go on! Don’t you say another word! I can’t bear it! Don’t you!” The Story Girl didn’t. But she had said enough. There was something in the quality of a ghost with eyeholes but no eyes that froze our young blood. There never were in all the world six more badly scared children than those who huddled in the old King orchard that August night. All at once—something—leaped from the bough of a tree and alighted before us. We split the air with a simultaneous shriek. We would have run, one and all, if there had been anywhere to run to. But there wasn’t—all around us were only those shadowy arcades. Then we saw with shame that it was only our Paddy. “Pat, Pat,” I said, picking him up, feeling a certain comfort in his soft, solid body. “Stay with us, old fellow.” But Pat would none of us. He struggled out of my clasp and disappeared over the long grasses with soundless leaps. He was no longer our tame, domestic, well acquainted Paddy. He was a strange, furtive animal—a “questing beast.” Presently the moon rose; but this only made matters worse. The shadows had been still before; now they moved and danced, as the night wind tossed the boughs. The old house, with its dreadful secret, was white and clear against the dark background of spruces. We were woefully tired, but we could not sit down because the grass was reeking with dew. “The Family Ghost only appears in daylight,” said the Story Girl. “I wouldn’t mind seeing a ghost in daylight. But after dark is another thing.” “There’s no such thing as a ghost,” I said contemptuously. Oh, how I wished I could believe it! “Then what rung that bell?” said Peter. “Bells don’t ring of themselves, I s’pose, specially when there ain’t any in the house to ring.” “Oh, will Uncle Roger never come home!” sobbed Felicity. “I know he’ll laugh at us awful, but it’s better to be laughed at than scared like this.” Uncle Roger did not come until nearly ten. Never was there a more welcome sound than the rumble of his wheels in the lane. We ran to the orchard gate and swarmed across the yard, just as Uncle Roger alighted at the front door. He stared at us in the moonlight. “Have you tormented any one into eating more bad berries, Felicity?” he demanded. “Oh, Uncle Roger, don’t go in,” implored Felicity seriously. “There’s something dreadful in there—something that rings a bell. Peter heard it. Don’t go in.” “There’s no use asking the meaning of this, I suppose,” said Uncle Roger with the calm of despair. “I’ve gave up trying to fathom you young ones. Peter, where’s the key? What yarn have you been telling?” “I DID hear a bell ring,” said Peter stubbornly. Uncle Roger unlocked and flung open the front door. As he did so, clear and sweet, rang out ten bell-like chimes. “That’s what I heard,” cried Peter. “There’s the bell!” We had to wait until Uncle Roger stopped laughing before we heard the explanation. We thought he never WOULD stop. “That’s Grandfather King’s old clock striking,” he said, as soon as he was able to speak. “Sammy Prott came along after tea, when you were away to the forge, Peter, and I gave him permission to clean the old clock. He had it going merrily in no time. And now it has almost frightened you poor little monkeys to death.” We heard Uncle Roger chuckling all the way to the barn. “Uncle Roger can laugh,” said Cecily, with a quiver in her voice, “but it’s no laughing matter to be so scared. I just feel sick, I was so frightened.” “I wouldn’t mind if he’d laugh once and have it done with it,” said Felicity bitterly. “But he’ll laugh at us for a year, and tell the story to every soul that comes to the place.” “You can’t blame him for that,” said the Story Girl. “I shall tell it, too. I don’t care if the joke is as much on myself as any one. A story is a story, no matter who it’s on. But it IS hateful to be laughed at—and grown-ups always do it. I never will when I’m grown up. I’ll remember better.” “It’s all Peter’s fault,” said Felicity. “I do think he might have had more sense than to take a clock striking for a bell ringing.” “I never heard that kind of a strike before,” protested Peter. “It don’t sound a bit like other clocks. And the door was shut and the sound kind o’ muffled. It’s all very fine to say you would have known what it was, but I don’t believe you would.” “I wouldn’t have,” said the Story Girl honestly. “I thought it WAS a bell when I heard it, and the door open, too. Let us be fair, Felicity.” “I’m dreadful tired,” sighed Cecily. We were all “dreadful tired,” for this was the third night of late hours and nerve racking strain. But it was over two hours since we had eaten the cookies, and Felicity suggested that a saucerful apiece of raspberries and cream would not be hard to take. It was not, for any one but Cecily, who couldn’t swallow a mouthful. “I’m glad father and mother will be back to-morrow night,” she said. “It’s too exciting when they’re away. That’s my opinion.” About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. L. M. Montgomery (2004). The Story Girl. Urbana, Illinois: Project Gutenberg. Retrieved https://www.gutenberg.org/cache/epub/5342/pg5342-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

E2XR

e2xr.io

-- employees

Since n.d.

COMPANY RANKING

E2XR

EVERGREEN INDEX #4144

Representing this company? Click here to claim and customize this page!

E2XR WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

E2XR

e2xr.io

-- employees

Since n.d.

COMPANY RANKING

E2XR

EVERGREEN INDEX #4144

RELATED COMPANIESRANK

STORIES ABOUT E2XR

Representing this company? Click here to claim and customize this page!

E2XR WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!